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INTRODUCTION 

An application system based on a custom hardware 
design will typically perform faster and require less 
hardware than if it were implemented with “off the 
shelf” circuit boards. However, these advantages are 
countered by the disadvantages of custom designs, with 
one of the largest drawbacks being the custom software 
required. This software is often unique to the applica- 
tion and specific to the hardware design, requiring a 
significant and increasing percentage of the develop- 
ment schedule and expense. The cost is multiplied by the 
need for software tools, standards, and maintenance 
developed specifically for each application. In addition, 
much of the application software cannot be used for 
new applications or hardware. All of these disadvan- 
tages can be significantly reduced by using a modular, 
standardized operating system. 

The operating system provides a higher level interface to 
the system hardware. The hardware characteristics com- 
m.on to most applications, such as memory management 
and interrupt handling, are handled by the operating 
system rather than the application software. The 
operating system provides scheduling and synchroniza- 
tion for multiple functions, allowing application code to 
be written in independent pieces or modules. The 
operating system interface can be more standardized 
then the interface to the hardware components. This 
allows the application software to be more independent 
of changing hardware. The application code can be in- 
itially implemented and debugged on proven hardware. 
The software is then easily moved to the final hardware 
configuration for testing. 


The operating system interfaces allow the use of stan- 
dard software tools, such as debuggers. Operating sys- 
tems also provide decreased debugging time and in- 
creased reliability through error checking and error 
handling. Perhaps most important, the expertise gained 
can be carried on to new designs based on the operating 
system. 

Operating systems have generally been described as 
large and complex, with rigid system requirements. 
Users have found it difficult to tailor a system to their 
needs or to use the operating system on more than one 
hardware configuration. System software has been ac- 
cepted in large pieces or as a whole, with few system 
configuration choices in either hardware or software. 
Those systems small enough to use on component de- 
signs have lacked extendibility to larger, more complex 
designs. 

The Intel iRMX 86 Operating System offers users of 
component hardware all benefits of operating systems 
while imposing few hardware restrictions. Minimum 
hardware requirements include 1.8K RAM memory, 
enough RAM or EPROM memory to hold the Nucleus 
and the application code, and a handful of integrated 
circuits. The circuits are an Intel iAPX 86 or iAPX 88 
Central Processing Unit, an Intel 8284 Clock Generator, 
Intel 8282/83 Latches for bus address lines, an Intel 
8253 Programmable Interval Timer, and an Intel 8259A 
Programmable Interrupt Controller. Larger system 
busses will also require an Intel 8288 Bus Controller and 
Intel 8286/87 Transceivers for data lines. This basic 
hardware system is shown in Figure 1. 



Figure 1. Basic Hardware System for the iRMX 86™ Operating System 
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Users with a wide range of applications will find the 
iRMX 86 Operating System allows them to implement a 
corresponding range of capabilities, from a minimum 
iRMX 86 Nucleus to a high level human interface. A 
complete iRMX 86 Operating System includes extensive 
I/O capabilities, debugger, application loader, boot- 
strap loader, and integrated user functions. This flexi- 
bility allows one operating system to be used for many 
projects, minimizing software learning curves for new 
applications. 

This note discusses a relatively small standalone spec- 
trum analysis system based on a subset of the iRMX 86 
Nucleus. The intent of the note is to demonstrate advan- 
tages of using operating systems in hardware compo- 
nent designs. An overview of operating system func- 
tions is given first as background information. Readers 
familiar with operating systems may wish to skip this 
section. The overview is followed by a summary of the 
iRMX 86 Operating System. The summary is brief, as 
only the iRMX 86 Nucleus is used in this application. A 
detailed discussion may be found in Application Note 
AP-86, “Using the iRMX 86 Operating System,” and 
iRMX 86 System Manuals. 

The spectrum analysis system is described after the sum- 
mary. me system icquiiemcms, ucsigii emu implemen- 
tation are detailed. The system software is discussed 
next, followed by configuration and hardware imple- 
mentation. A summary completes the application note 
text. Partial code listings of the system software are in- 
cluded in the appendices. 


OPERATING SYSTEMS FUNCTIONAL 
OVERVIEW 

Operating system software manage initialization, 
resources, scheduling, synchronization, and protection 
of tasks or functions within the system, as well as pro- 
viding facilities for maintenance, debugging, and 
growth. In general, operating systems support many of 
the following: 

Multiprogramming 

Multiprogramming provides the capability for two or 
more programs to share the system hardware, after 
being developed and implemented independently. 
Within the environment of an operating system, the 
programs are called jobs. Jobs include system resources, 
such as memory, in addition to the actual program 
code. Multiprogramming allows jobs that are required 
only during development, such as debuggers, to run in 
the target system. When development is completed, 
these jobs are removed from the final system without af- 
fecting the integrity of the remaining jobs. 


Multitasking 

Multitasking allows functions within a job to be han- 
dled by separate tasks. This is particularly valuable 
when a job is responsible for multiple asynchronous 
events or activities. One task can be assigned to each 
event or activity. Tasks are the functional members of 
the system, executing within the bounds of a job en- 
vironment. Program code for a multitasking system is 
modular, with well-defined interfaces and communica- 
tion protocols. The modular boundaries serve several 
important purposes. The code for each module can be 
generated and tested independent of the other modules. 
In addition, the boundaries confine errors, speeding 
debugging and simplifying maintenance. 

Growth 

The modular independence that results from multipro- 
gramming and multitasking gives users the ability to ef- 
ficiently create new applications by adding functions to 
old software. Applications can be tailored to specific 
needs by integrating new modules with previously- 
written general support code. If care is taken in system 
design, functions can be added in the field. Documenta- 
tion for the older software can be carried on to the new 
applications. This growth path will save completely re- 
writing expensive custom software for each new applica- 
tion. 

Scheduling 

Even though a system has multiple jobs and tasks, only 
one task is actually running on the central processor at 
any single point in time. Scheduling provides a means of 
predicting and controlling the selection of the running 
task from the tasks that are ready to run. Basic sched- 
uling methods include preemptive priority, non-pre- 
emptive priority, time-slice, and round-robin. Batch 
systems often use non-preemptive priority scheduling, 
in which the highest priority job gets control of the cen- 
tral processor and runs to completion. Preemptive 
scheduling is typically used in real-time or event-driven 
systems, where dedicated, quick response is the main 
concern. A higher-priority waiting task that becomes 
ready to run will preempt the lower-priority running 
task. Priority may be either set at task creation (static) 
or modified during running of the task (dynamic). 

Time-slice and round-robin scheduling are used in 
multiuser or multitask systems that share processing 
resources and have limits on maximum execution time. 
Time-slice scheduling gives each task or job a fixed slice 
of dedicated processor time. Round-robin gives each 
task or job a turn at using the processor. The time avail- 
able during the turn depends on system load and task 
priority. 
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Communication and Synchronization 

Jobs and tasks in a multiprogramming and multitasking 
environment require a structured means of communica- 
tion. This communication may be necessary to syn- 
chronize processes or to pass data between processes. 
Two means of providing communication are mailboxes 
and semaphores. Mailboxes are an exchange place for 
system messages. The messages may include data or 
provide access to other system objects, including other 
mailboxes. Tasks can send objects to a mailbox or wait 
for objects from a mailbox. Generally, the task has the 
option of waiting for a specified period of time for the 
message. The wait time may range from zero for a task 
that requires immediate response to infinite time for a 
task that must have a message to continue processing. 
Multiple mailboxes are used to synchronize multiple 
tasks. 


A communication flow using mailboxes is shown in Fig- 
ure 2. In this example, the sending task sends a message 
to a mailbox and specifies a return mailbox. The send- 
ing task then waits at the return mailbox. The receiving 
task obtains the message from the sending mailbox and 
sends a message to the return mailbox. The first task 
obtains the second message from the return mailbox, 
synchronizing the two tasks and passing data. 



Figure 2. intertask Communications with 
Maiiboxes 


If process synchronization is the only requirement, sem- 
aphores may be used. Semaphores function like mail- 
boxes except that no data is passed through the sema- 
phore. Instead, semaphores contain “units,” with the 


meaning of the units defined by the sending and receiv- 
ing tasks. A one unit semaphore may be used as a flag to 
synchronize the tasks. Multiple unit semaphores can be 
used for resource control. For example, if tasks require 
reusable data buffers, a semaphore may be defined as 
the allocator of the available data buffers. Each unit in 
the semaphore will represent one available buffer. 
When a task requires buffers to continue, the task will 
wait at the semaphore until enough units (representing 


buffers) are available. The waiting task will receive the 
units, use the buffers, and return the units (still 
representing buffers) to the semaphore. Other tasks that 
require buffers will also have to wait at the semaphore 
until enough buffers are available. 


Resource Management 

The operating system is the central guardian of system 
resources, specifically read/write memory. The memory 
is made known to the Nucleus at initialization. The 
Nucleus then gives pieces or segments of the memory to 
tasks as they request it. This allows the tasks to have no 
initial knowledge of the actual location and size of sys- 
tem memory. Tasks can share memory if they desire, 
but the Nucleus allocates memory to each task individ- 
ually, preventing the tasks from using each others mem- 
ory. In addition, tasks return memory to the Nucleus 
when they are through with it, allowing memory to be 
reused. 

Other system resources, such as I/O devices, will also be 
scheduled by the operating system. The operating sys- 
tem is responsible both for the efficient use of these 
resources and for providing the tasks with a large mea- 
sure of independence from the actual I/O hardware re- 
quirements. The system may require many types of I/O 
devices, such as disk drives, tape drives, and printers. 
I/O is more efficiently accomplished if the operating 
system provides both asynchronous and synchronous 
I/O operations. Synchronous operations are those the 
task starts and waits for completion, doing no other 
work until the I/O is complete. Asynchronous opera- 
tions are started by the task, but the actual I/O can take 
place while the task is doing other work. The overlapped 
operation of asynchronous I/O provides more user con- 
trol of the I/O operation at the expense of a more com- 
plicated user interface. 

Interrupt Management 

Real-time software is tightly coupled to hardware func- 
tions by interrupts. Interrupts provide rapid notification 
that the hardware needs attention. The software must 
respond quickly without corrupting the system environ- 
ment. System integrity is preserved by preempting the 
lower priority operating task, saving the task environ- 
ment, processing the interrupt (including communicat- 
ing the results to other tasks if necessary), restoring the 
environment of the operating task, and continuing. All 
of this must occur in an orderly and efficient manner. 
The interrupt management of the operating system is 
responsible for directly interacting with the system hard- 
ware that detects interrupts. The interrupt tasks can be 
ignorant of the detailed interrupt hardware, providing 
only the system actions to service the event that caused 
the interrupt. 
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Initialization 

Operating systems create and manage jobs and tasks at 
initialization as well as run time. Initialization generally 
must be done in a specific sequence which will depend 
on the environment existing at that time. An abortive in- 
itialization environment may require an orderly shut- 
down of the system. The operating system has the 
capability for managing these situations, including com- 
munications, access to system resource information, 
and displaying status of the initialization actions. 

Debugging 

The system debugger is a window into the internal struc- 
tures of the operating system. Debuggers allow data 
structures and memory to be examined, breakpoints to 
be set, and the user to be notified of abnormal condi- 
tions. The debugger may have symbolic debugging, in 
which system objects such as addresses, tasks, jobs, 
mailboxes, and memory locations can be assigned 
names. This gives greater flexibility and accuracy during 
debugging. The debugger may not be necessary in the 
final system, so the debugger is often a separate system 
job. This allows removal of the debugger with no effect 
on the remaining jobs. 

Debugging will be aided if the operating system verifies 
the parameters required by system actions and also re- 
turns status for the requested action. Parameter verifi- 
cation is particularly valuable for new program code in 
a developing system. Status results other than success 
are abnormal or exception conditions. Exception condi- 
tions may include insufficient memory for the request, 
invalid input data, inoperative I/O devices, an invalid 
request for an action, or a request for an invalid action. 
The operating system may have an exception handler 
for these conditions and may allow the debugger to be 
used as the exception handler. The development process 
will be more efficient if detection of exception condi- 
tions takes place for all levels of system actions, from 
initialization of jobs and tasks to requests for memory 
or status. 


Higher Level Functions 

With the continuing increase in system complexity, 
more operating systems are providing higher level func- 
tions. These functions may include advanced I/O file 
management, operator console, spooling operations, 
telecommunications support, multiuser support and ac- 
cess to system resources of increasing size and complex- 
ity. Only the largest operating systems provide all of 
these capabilities, but users of component hardware 
must be careful their system will integrate higher level 
functions that may be required in future applications. 


Extendibility 

In order to provide general purpose support, operating 
systems must be extendible. New applications may re- 
quire data structures or system actions not available 
with the present operating system. The system must be 
able to integrate these new structures and actions, sup- 
porting them in the same manner as existing functions. 
Choosing an operating system requires a large commit- 
ment, both in initial expense and system architecture. 
Extendibility provides assurance the operating system 
chosen will not provide built-in obsolescence of that 
commitment. 

iRMX 86^'^ OPERATING SYSTEM 
ARCHITECTURE 

Layers 

The iRMX 86 Operating System architecture is shown in 
Figure 3. It includes the Nucleus, Basic I/O System, Ex- 
tended I/O System, Applications Loader, and Human 
Interface. These major portions of the operating system 
are designed as layers. Each layer may be added to 
previous layers as application needs grow. Lower layers 
may be used without upper layers. All layers may reside 
in programmable read only memory. Applications have 
access to an portions oi me system, irom me iNucieus to 
all outer layers. 



Figure 3. Architecture of the iRMX 86^'^ 
Operating System 


The Nucleus is the heart of the system. It includes sup- 
port for multiprogramming, multitasking, communica- 
tions, synchronization, scheduling, resource manage- 
ment, extendibility, interrupt handling, and error detec- 
tion. The Nucleus may be considered as an extended 
layer of the underlying hardware, giving the hardware 
system management functions and making the software 
independent of the detailed hardware. The system en- 
vironment, including resources, priorities, and place- 
ment of program code, is made known to the Nucleus at 
system initialization. All requests for memory, com- 
munication, and creation of basic data structures must 
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go through the Nucleus. These requests are made by 
system calls, which are comparable to subroutine calls 
for system actions. 

All higher level functions of the iRMX 86 Operating 
System are built around a core of the Nucleus. Although 
outer layers may require a substantial number of the 
system functions included in the Nucleus, the Nucleus 
itself is configurable on a call-by-call basis. “Configu- 
rable” means the Nucleus may be altered so it contains 
code only for those functions required by the applica- 
tion. Certain features, such as parameter validation and 
exception handling, are also configurable. Features and 
system calls may be included for development and ex- 
cluded from the final system, giving a Nucleus tailored 
for each level of application development. 

The Basic I/O System is the first layer above the 
Nucleus. The Basic I/O System provides asynchronous 
I/O support and format independent manipulation of 
data. Multiple file types are supported, including 
Stream, Named, and Physical files. Stream files are in- 
ternal files for transferring large amounts of data be- 
tween jobs or tasks. Named files include data files of 
varying sizes and directories for those files. Named files 
are designed for random access disk storage. Physical 
files consider the entire device to be one file. Physical 
files are primarily used to transfer data to and from 
printers, tape drivers, and terminals. Device drivers for 
both floppy and hard disks are provided. Like the 
Nucleus, the Basic I/O System provides system calls to 
invoke I/O actions. These calls and the features of the 
Basic I/O System are fully configurable. 

The Application Loader provides the ability to load 
code and data from mass storage devices into system 
RAM memory. The Application Loader resides on the 
Basic I/O System, allowing application code to be 
loaded from any random access device supported by the 
Basic I/O System. Application code can be loaded and 
executed as needed rather than residing in dedicated 
system memory. 

The Extended I/O System supports synchronous I/O, 
automatic buffering, and logical names. Synchronous 
I/O provides a simplified user interface for I/O actions. 
Automatic buffering improves I/O efficiency by over- 
lapping 1/ O and application operations wherever possi- 
ble. Logical name support allows applications to access 
files with a user-selected name, aiding I/O device inde- 
pendence. 

The Human Interface uses all lower layers, forming a 
high level man-machine interface for user program in- 
vocation, command parsing, and file utilities. The 
primary purpose of the Human Interface is to support 
the addition of interactive commands. The Human In- 
terface is the basis for pass-through language support 
and multiple user systems. 


Configurability 

Configurability means the iRMX 86 Operating System 
can be changed to include only the system calls and 
features pertinent to the system under development. 
Smaller applications start with only the iRMX 86 
Nucleus. A subset of Nucleus calls, described later in 
this application note, provide the basis for management 
of jobs, tasks, memory, interrupts, communication and 
synchronization, and support for the Debugger and Ter- 
minal Handler. 

All systems calls may also use parameter validation as a 
configuration option. Parameter validation verifies that 
system calls reference correct system objects before the 
requested action is performed. During debugging and in 
hostile environments, validation provides error detec- 
tion for each system call. This error detection does add 
some overhead to the calls. Debugged application jobs 
can perform more efficiently without the validation, 
while new code can use parameter validation to speed 
development. 

Once errors are detected, there are two means available 
to handle error recovery. The task can either use the 
status information to perform error recovery actions or 
the recovery actions may be performed by a specialized 
error handling program called an exception handler. 
Applications may use the Debugger as an exception 
handler, or use one implemented by the application. 
There are two classes of errors that may cause control to 
be given to an exception handler; avoidable errors, such 
as programmer errors, and unavoidable errors, such as 
insufficient memory. Exception handlers can be selected 
to receive control for either or both classes. 

Support Functions 

The iRMX 86 Operating System includes a Debugger, a 
Terminal Handler, a Bootstrap Loader, and a Patch 
Facility. The Debugger examines system objects, using 
execution and exchange (mailbox and semaphore) 
breakpoints, symbolic debugging, and exception han- 
dling. The Terminal Handler provides a line-editing, 
mailbox-driven CRT communications capability. The 
Bootstrap Loader is a fully configurable loader for 
bootstrap loading on reset or command, from any spe- 
cific random access device. The Patch Facility gives the 
capability of patching iRMX 86 Object Code in the 
field. 

Object Orientation 

The iRMX 86 Operating System is based on a set of sys- 
tem data structures called objects. These objects include 
jobs, tasks, mailboxes, semaphores, segments, and 
regions. Users may also define application-specific ob- 
jects. Object architecture includes the objects, their 
parameters, and the functions allowed with the objects. 
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Object orientation is a formal, hardware-independent 
definition of hardware-dependent system structures that 
are currently used by most applications. For example, 
without object orientation, memory is reserved in ad- 
vance for system buffers. The application code knows 
buffer sizes and locations. If buffer requirements grow, 
requiring a new memory layout, much of the applica- 
tion code will change to accommodate the new buffer 
sizes and locations. Using object orientation, the ap- 
plication requests a segment (buffer) of a particular size 
when the buffer is needed. The Nucleus allocates the 
memory and returns a segment object to the applica- 
tion. If the application needs a larger buffer, it returns 
the old segment and requests a new one of a larger size. 
The application obtains more buffers by making re- 
quests for more segments. If the hardware changes, the 
iRMX 86 Operating System is made aware of the 
changes. The application code uses the same system 
calls to request and return the segment objects 
regardless of the hardware configuration. 

Objects are provided for modular environments Gobs), 
application code functions (tasks), communication 
(mailboxes), synchronization (semaphores), memory 
(segments), and mutual exclusion (regions). Objects are 
fundamentally a set of standard interfaces between ap- 
piicrtuuii couc culu iiic iiviviyv 60 wpciauug i 6 yj>Lclii, me 
Standard interfaces have three primary benefits: 

1) First, objects provide structures, such as tasks or seg- 
ments, that are common to all applications. The 
structures form the basis for a standard set of system 
calls that make the interface between the application 
and the operating system more consistent and easier 
to learn. These calls allow applications to create more 
objects (segments for buffers, for example), delete 
them, change them, and inspect them. Development 
engineers can use their knowledge of the objects on 
many applications, rather than just the one under 
development. The common objects allow a common 
system debugger to be used. The debugger will work 
for all applications, letting engineers concentrate 
their efforts on the application itself rather than 
designing and implementing custom debugging tools. 

2) Second, the standard characteristics of the object 
allow consistent error detection and handling. Re- 
quests to alter or use objects can be checked for 
validity before the Nucleus actually performs the re- 
quest. Errors can be classed as common to all objects 
or specific to certain objects, giving more precise 
error information for effective error handling and 
faster debugging. 

3) Third, the object interface will be preserved on future 
releases of the iRMX 86 Operating System. Current 
application code can be split into independent 
modules. Future applications can use the modules for 


common functions, preserving the investment in ap- 
plication software. 

Task Scheduling 

The Nucleus controls task scheduling by task priority 
and task state. Task priority is specified when the task is 
created. The priority can be altered dynamically. Tasks 
are classified into one of five classes: Running, Ready, 
Asleep, Suspended, or Asleep-Suspended. Tasks that 
have not been created are considered to be non-existent. 
The State Transition Diagram is shown in Figure 4. 


Figure 4. State Transition Diagram 

Only one task is in the Running state. This task has con- 
trol of the central processor. The Ready state is occu- 
pied by those tasks that are ready to run but have lower 
priority than the Running task. The Asleep state is occu- 
pied by tasks waiting for a message, semaphore units, 
availability of a requested resource, an interrupt, or for 
a requested amount of time to elapse. A task can specify 
the amount of time it will allow itself to spend in the 
Asleep state, but tasks in the Suspended state must be 
“resumed” by other tasks. The Suspended state is use- 
ful when situations require firm scheduling beyond the 
control provided by priority and system resource avail- 
ability. Examples of these situations are system emer- 
gencies, controlling tasks in the Ready state for applica- 
tion-dependent scheduling algorithms, and guarantee- 
ing a fixed initialization or shut-down sequence. If 
another task “suspends” a task already in the Asleep 
state, the sleeping task goes to the Asleep-Suspended 
state. This task will enter the Suspended state if the 
sleep-causing condition is satisfied. The task will go to 
the Asleep state from the Asleep-Suspended state if it is 
resumed before the sleep-causing condition is removed. 
If a task enters the Ready state and has higher priority 
than the present Running task, the Ready task is given 
control of the CPU. Control is transferred to another 
task only when: 

1) The Running task makes a request that cannot im- 
mediately be filled. The Running task is moved to the 
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Asleep state. The highest-priority Ready task be- 
comes the Running task. 

2) An interrupt occurs, causing a higher-priority task to 
become Ready. The current Running task goes to the 
Ready state, allowing the higher-priority task to 
become the Running task. 

3) The Running task causes a higher-priority task to 
become Ready by releasing the resource for which the 
higher-priority task is waiting. The current Running 
task goes to the Ready state. The higher-priority task 
becomes the Running task. 

4) The Running task causes a higher-priority task to 
become Ready by sending a message or semaphore 
units to the mailbox or semaphore where the higher- 
priority task is waiting. The Running task is moved 
to the Ready state. The higher-priority task becomes 
the new Running task. 

5) The Running task removes a higher-priority task 
from the Suspended state by “resuming” it, placing 
the higher-priority task in the Ready state. The cur- 
rent Running task is moved to the Ready state and 
the higher-priority Ready task becomes the new Run- 
ning task. 

6) The Running task creates a higher-priority task. The 
new task goes to the Ready state. The current Run- 
ning task is moved to the Ready state and the higher- 
priority Ready task becomes the new Running task. 

7) The Running task places itself in the Suspended state. 
The highest-priority Ready task becomes the new 
Running task. 

8) The Running task places itself in the Asleep state. 
The highest-priority Ready task becomes the new 
Running Task. 

9) The Running task deletes itself, becoming Non- 
existent. The highest-priority Ready task will be the 
new Running task. 

System Hardware Requirements 

The iRMX 86 Operating System will run on any system 

that meets the following minimum hardware require- 
ments; 

1) An iAPX 86 or iAPX 88 Central Processing Unit. 

2) An Intel 8253 Programmable Interval Timer to pro- 
vide the system clock. 

3) An Intel 8259A Programmable Interrupt Controller. 

4) Enough hardware to provide a system clock and bus 
interfaces. This may be supplied by the Intel 8284 
Clock Generator, Intel 8288 Bus Controller, Intel 
8282/8283 Latches, and Intel 8286/8287 Transceiv- 
ers. 


5) The following RAM: 

a. 1024 bytes from 0 to 1024 for software interrupt 
pointers (the interrupt vector). 

b. 800 bytes for Nucleus data. 

c. Enough RAM for the application data, code, and 
system objects. 

6) Enough EPROM or RAM to hold the required parts 
of the iRMX 86 Operating System and the applica- 
tion code. 

The Intel iSBC 86/12A Single Board Computer more 
than meets these minimum requirements. A block dia- 
gram of the board is shown in Figure 5. Note in addition 
to the timer and interrupt controller the board contains 
an 8251 A USART, an 8255 parallel I/O interface, a 
MULTIBUS™ interface, four sockets for up to 16K 
bytes of EPROM, and 32K bytes of dual-ported RAM. 
Even though a user may be developing a custom board 
for his application, it is recommended that initial system 
development be accomplished using the iSBC 86/12A 
Single Board Computer. This will provide a known 
hardware environment to simplify debugging. In addi- 
tion, the development hardware system can be adapted 
to changing application needs by adding Intel MULTI- 
BUS compatible boards to the iSBC 86/12A Single 
Board Computer. After the software is fully debugged, 
the application can be moved to the final custom hard- 
ware design. 

APPLICATION EXAMPLE 

A spectrum analyzer is the subject of this application. 
The analyzer displays the frequency spectrum of an 
analog signal on a general purpose CRT terminal. The 
user has control over input signal bandwidth, averaging, 
and continuous analysis. A fast Fourier transform 
(FFT) program is used to obtain frequency data from 
samples of analog data. Fourier transforms provide use- 
ful frequency analysis, but the large processing require- 
ments of Fourier transforms have restricted their use. 
Fast Fourier transforms take advantage of the repetitive 
nature of the Fourier calculations, allowing the Fourier 
transforms to be completed significantly faster. The 
FFT used in this application note is known as “time de- 
composition with input bit reversal.”^ Sixteen-bit inte- 
ger samples of the input signal are placed in frames, 
with each frame holding 128 complex points. An aver- 
aged power spectrum is calculated to sum and square 
the FFT values, yielding 64 32-bit power spectrum 
values. These values are displayed on a standard CRT 
terminal. 


1. S. O. Stearns, Digital Signal Analysis, Hayden Book Co., Rochelle 
Park, NJ, 1975. 
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Figure 5. iSBC 86/1 Single Board Computer Block Diagram 


The FFT algorithm may be applied wherever frequency 
analysis of an analog signal is required. Medical appli- 
cations for FFTs include EEG analysis, blood flow 
analysis, and analysis of other low-frequency body sig- 
nals. Industrial uses are production line testing, wear 
analysis, frequency signature monitoring, analysis in 
noisy or hostile environments, and vibration analysis. 
Other applications could cover remote reduction of 
analog data, frequency correlation, and process control. 
For this application note, the actual use of the FFT is 
secondary to its existence as a modular, CPU-intensive 
task in a general purpose system. 

The overall application system characteristics are the 
following: 

1) A user-selectable input signal bandwidth of 120 Hz, 
600 Hz, 1200 Hz, 6000 Hz, or 12,000 Hz. 

2) The option of averaging frames of samples. The 
averaging is user selectable, with options of 1 (no 
averaging), 2, 4, 8, 16, or 32 frames averaged per 
CRT display. 

3 )The capability, also user selectable, of repeating the 
analysis cycle continuously. 


4) User capability to abort the analysis, 

5) Twelve-bit input sample resolution. 

6) A minimum of hardware requirements, including no 
more than 32K bytes of EPROM memory and 16K 
bytes of RAM memory. 

7) A standard character screen CRT for output. 

8) A multitasking structured design that will use a 
subset of the iRMX 86 Nucleus and exhibit modular 
application code, formal interfaces, and self- 
documentation. 

System Design 

To begin the design, the application is broken up into 
functional modules, much the same as a hardware block 
diagram, A SUPERVISOR TASK initializes the system, 
accepts operator parameters, starts the analysis cycle, 
and stops the processing upon cycle completion or 
operator request. An INPUT TASK samples the data 
and places it in a buffer. An FFT TASK receives the 
buffer and processes the data. An OUTPUT TASK dis- 
plays the data received from the FFT TASK, This struc- 
ture is shown in Figure 6. 
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Figure 6. Basic Application Architecture 


The general task functions are: 

SUPERVISOR TASK: The SUPERVISOR TASK ini- 
tializes the system by creating the other tasks. The 
SUPERVISOR TASK then obtains the analysis param- 
eters from the operator. Each parameter is verified as it 
is received. When all of the parameters are accepted, the 
operator is asked if they are satisfactory. If the operator 
agrees, the SUPERVISOR TASK sends frame buffers 
to the INPUT TASK to initialize the analysis. If not, the 
operator is asked to input all of the parameters again. 
During the EFT analysis, the SUPERVISOR TASK 
waits for an abort request from the operator and for the 
frame buffer from the OUTPUT TASK. If the abort re- 
quest is received, the SUPERVISOR TASK terminates 
the analysis in an orderly fashion and asks the operator 
for parameters for the next analysis cycle. If the frame 
buffer is received from the OUTPUT TASK and con- 
tinuous analysis has been selected, the SUPERVISOR 
TASK sends the frame buffer to the INPUT TASK to 
start the next cycle. If the frame buffer is received from 
the OUTPUT TASK and continuous analysis has not 
been selected, the current analysis is complete and the 
SUPERVISOR TASK asks for new parameters. 

INPUT TASK: The INPUT TASK receives the frame 
buffer from the SUPERVISOR TASK. The input signal 
is sampled according to the analysis parameters. The 
actual sample rates are calculated as follows: 

1) Multiply the highest frequency of interest by two to 
obtain the Nyquist sampling rate. 

2) Invert this value to obtain time between samples. 

3) Scale the value by 60/64. The CRT display is limited 
to 64 columns. The scaling maps sample values to 
columns 1 to 60 rather than 1 to 64, giving a more 
readable x-axis label and display. This method yields 
sample times of 3.9 milliseconds, 781 microseconds, 
390 microseconds, 78 microseconds, and 39 micro- 
seconds for frequencies of 120 Hz, 600 Hz, 1200 Hz, 
6000 Hz, and 12,000 Hz. 

The INPUT TASK samples the data at the required 
interval and places the samples in the frame buffer. 
When the frame buffer is full, the INPUT TASK up- 


dates the frame buffer number and sends the frame buf- 
fer to the FFT TASK. The INPUT TASK sends a status 
message to the CRT terminal and waits for the next 
frame buffer. 

FFT TASK: The FFT TASK receives the frame buffer 
from the INPUT TASK. A fast Fourier transform is 
performed on the data contained in the buffer, the 
power spectrum is calculated, and the data is averaged 
with previous data if necessary. If the frame buffer is 
the last one to be averaged prior to display of the fre- 
quency data, the frame buffer is filled with the averaged 
data and sent to the OUTPUT TASK. If the buffer is 
not the last one to be averaged, the FFT TASK returns 
the buffer to the INPUT TASK for another frame of 
data or to the SUPERVISOR TASK if the analysis cycle 
is nearly complete. The FFT TASK sends status infor- 
mation to the CRT display and waits for the next frame 
buffer from the INPUT TASK. 

OUTPUT TASK: The OUTPUT TASK receives the 
frame buffer from the FFT TASK. The data is format- 
ted and displayed. The OUTPUT TASK sends the 
frame buffer to the SUPERVISOR TASK and waits for 
the next frame buffer from the FFT TASK. 

Terminal Handler: The Terminal Handler serves as the 
basic I/O device for parameter requests, status data, 
and frequency displays. The Terminal Handler accepts 
display requests from all tasks and sends operator input 
to the SUPERVISOR TASK. 

The basic functions of the various tasks in the applica- 
tion have been defined, but system integration has not 
been discussed. Synchronization of the tasks, schedul- 
ing, resource management, mapping to hardware, inter- 
rupt handling, and system interfaces have been omitted. 
No debugging functions have been defined. It is clear 
the system implementation is just started. The iRMX 86 
Nucleus will provide all of the system integration 
“glue” the application requires, allowing application 
programmers to concentrate on the actual functional 
code. In order to use this “glue,” the application must 
be divided into jobs and tasks. 

Jobs and Tasks 

The iRMX 86 Operating System architecture defines 
jobs as separate environments within which tasks oper- 
ate. These separate environments allow each job to 
function with no knowledge of other system jobs. There 
are two jobs in this application, the Debugger job and 
the Application job. 

The jobs contain functional portions or working pro- 
grams called tasks. The Application job contains the 
INIT TASK, SUPERVISOR TASK, INPUT TASK, 
FFT TASK, OUTPUT TASK, and INTERRUPT 
TASK. The Debugger job contains the Debugger task 
and the Terminal Handler task. Tasks provide the ap- 
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plication goals of modularity, resource constraint boun- 
daries, and functional independence. The structure of 
the development system is shown in Figure 7. 


of characters the Terminal Handler did read or write, a 
status field for the operation, and the actual data. The 
buffer format is shown in Figure 9. Figure 12 contains 
the Terminal Handler segment format. 


DEBUGGER 

TASK 


TERMINAL 

HANDLER 

TASK 


DEBUGGER 

JOB 



BEGINNING OF 
segment' 


APPLICATION 

JOB 


Figure 7. Development System Job Structure 

The Debugger job is included only for development. 
When development is completed, the Debugger job is 
removed from the system. A Terminal Handler job con- 
taining only the Terminal Handler task is substituted in 
place of the Debugger job. The application code is not 
changed. This structure is shown in Figure 8. 
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Figure 8. Final System Job Structure 

Interfaces and Synchronization 

Now that the system is made of jobs and tasks, the 
primary need is to synchronize the tasks and provide 
communication interfaces. This will be handled by mail- 
boxes. The messages sent via the mailboxes will be seg- 
ments, which are pieces of memory allocated by the 
Nucleus. The frame buffers sent from task to task are 
these segments. The buffer segments contain all the 
analysis parameters in addition to the data samples. 
Communication with the Terminal Handler task is also 
accomplished by mailboxes, but with a different buffer 
format. The Terminal Handler format has fields for the 
operation requested (read or write), the number of 
characters the task wishes to read or write, the number 


SAMPLES PER FRAME 


SAMPLE INTERVAL 


FRAMES TO AVERAGE 


CONTINUOUS FLAG 


THIS FRAME NUMBER 


NUMBER SAMPLES MISSED 


SAMPLE POINTER 


RESET FLAG 


DATA SAMPLES 


DATA SAMPLES 


Figure 9. Frame Buffer Format 

Mailboxes are used to pass the buffer segment from task 
to task. Tasks can send segments to mailboxes, or 
receive segments from mailboxes. If there is no segment 
at a mailbox, a task can elect to wait for the segment, 
wiin me wait uuraiion ranging irom zero lo lorever. 
This provides the simplest system synchronization — 
each task, upon initialization, waits at its input mailbox 
for a frame buffer segment. When the task receives the 
segment, it processes the data, sends the segment on to 
the mailbox for the next task, and returns to its own 
mailbox to wait for the next frame buffer. The system is 
synchronized and controlled by the availability of frame 
buffers and task priority. It should be clear that multi- 
ple frame buffers segments provide overlapped process- 
ing, with the segments ultimately “piling up” at the 
slowest task in the chain. This loose coupling arrange- 
ment allows tasks to have radically different execution 
times. For example, the INPUT TASK has an input 
sampling time that ranges from 0.6 seconds to 6.3 milli- 
seconds, a range of 100 to 1, and the system requires no 
special synchronization or scheduling to accommodate 
this range. 

The mailbox interfaces, shown in Figure 10, serve 
several other important purposes. First, they provide 
the standardized interface that is a goal of this applica- 
tion. The set of mailboxes and the two buffer segments 
form all inter-task interfaces. Each task uses only a few 
mailboxes, making it easy to add or remove tasks by 
adding or removing mailboxes. The system could easily 
be expanded to include data reduction tasks, data cor- 
relation tasks, or to substitute different tasks for any of 
the present ones. Dummy tasks were used for real tasks 
during development to verify overall system execution 
before the actual tasks were available. 
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Figure 10. Application Architecture with 
Mailboxes. 


The mailboxes also provide a very convenient window 
into the application system processing for both debugg- 
ing and aborting the current cycle. The Debugger can set 
breakpoints at mailboxes to allow users to examine the 
frame buffers as they progress from task to task. The 
Debugger can examine buffer data and control the pro- 
cessing cycle. Tasks wait at the mailboxes in a queue 
that is either priority or first-in-first-out (FIFO) based. 
The inter-task mailbox queues are priority based, which 
means the higher priority SUPERVISOR TASK can in- 
tercept segments at the mailboxes ahead of the lower 
priority waiting tasks, and abort the analysis by remov- 
ing all of the buffer segments. This method of aborting 
requires no knowledge of the internal processing of the 
tasks, making it universally applicable to all the tasks. 

A return mailbox may be specified when a segment is 
sent to a mailbox. The receiving task may send status in- 
formation, a different segment, or the original segment 
to the return mailbox. The Terminal Handler will return 


the buffer segment sent to it if a return mailbox is 
specified. This is used to synchronize the tasks with the 
Terminal Handler and to allow multiple tasks to use a 
single display task. Each sending task waits at a separate 
return mailbox for the Terminal Handler to return its 
segment. Each task retains control over its buffer seg- 
ment and is synchronized with the slower data display 
function. 

Priority 

In addition to the mailboxes, task execution is governed 
by priority. In this system, the INPUT TASK has maxi- 
mum priority to guarantee it can sample the input signal 
at the precise intervals required for the FFT. The 
SUPERVISOR TASK, responsible for abort functions, 
has the next level of priority, with the FFT TASK next, 
and the OUTPUT TASK lowest. 

APPLICATION IMPLEMENTATION 
Display Functions 

All application tasks use the iRMX 86 Terminal Han- 
dler as an output device. The Terminal Handler is 
chosen because it provides a standard interface consis- 
tent with the application goals, it exists both in the De- 
bugger job and in an independent job, and it is easy to 
integrate into the application system. The application 
could also use the same interface with a user-written 
Terminal Handler. In this application, the Terminal 
Handler can have messages from four tasks on the 
screen at one time. To allow this to occur in an orderly 
fashion, lines on the screens are reserved for each of the 
tasks. The screen format is shown in Figure 11. Each 
message to the screen sends the cursor to the upper left 
corner (the home position), then down to the proper line 
to display the data. 
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Current settings are the following; frequency range 0 to 6000 Hz, 

The INPUT TASK has processed 16 frames out of 16 frames to average. 
The FFT TASK has processed 16 frames out of 16 frames to average. 
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Figure 11. CRT Screen Display Format 
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Cataloging 

To aid the debugging process, all system objects, such as 
mailboxes, segments, and tasks, are cataloged in the 
directory of the SUPERVISOR TASK. The catalog en- 
tries are user-selected, 12-character names. The Debug- 
ger can display this directory, giving easy access to ob- 
jects to aid symbolic debugging. If other tasks know the 
proper directory and the 12-character name, the tasks 
can look up the objects in the directory and obtain ac- 
cess to them. This is the method used to find the Ter- 
minal Handler mailboxes. For objects that are cataloged 
only to aid debugging, the system calls that catalog the 
objects are removed from the code when debugging is 
complete. 

Application Code 

The code listings for the SUPERVISOR TASK and the 
INPUT TASK are included in appendices to this note. 
Code listings for other tasks are not included, but they 
are available from the Intel Insite software library. The 
following discussions reference line numbers in the list- 
ings included in this note. The references begin with a 
first letter for the appendix section (A or B), followed 
by the actual line number (A. 220, for example). 

ourcnviov/n iMOirx 

Code listings for the SUPERVISOR TASK are in Ap- 
pendix A. The actual SUPERVISOR TASK procedure 
begins at line A. 550. After initializing internal buffers 
and mailboxes (A.551, A.518-A.549), the Supervisor 
sends an initial screen, one line at a time, to the Termi- 
nal Handler (A.553, A.502-A.517). When the screen is 
complete, the SUPERVISOR TASK creates the INPUT 
TASK, FFT TASK, and OUTPUT TASK (A.554, 
A.486-A501). The order of creation is not important 
for this application, as each task begins by waiting at its 
input mailbox for frame buffer segments. The SUPER- 
VISOR TASK requests input parameters from the oper- 
ator (A. 556, A.305-A.485). The actual input parameter 
loop is found at A.478. The loop consists of asking 
questions (A.479, A.480) until all answers are satisfac- 
tory. The operator is asked to choose the highest fre- 
quency of interest, number of frames to average, and 
single runs or continuous runs (A.331-A.353). If the 
operator answers with an invalid input, the question is 
repeated (A. 365 and A. 41 5). If the operator wishes to 
abort the questioning by entering a 99, the questions 
start over from the first question (A.409-A.413). When 
all three questions have been answered, the operator is 
asked to confirm his choice (A.482, A.418-A.467). If 
the operator does not verify the answers, the question 
number is set to 0 (A. 463) and the parameters are re- 
quested again. If he confirms the answers as correct, the 
SUPERVISOR TASK creates up to three frame buffer 
segments (A.557, A.279-A.304). The SUPERVISOR 


TASK places the binary equivalents of the operator 
answers in the frame segments (A. 284, A. 292, A. 300, 

A. 269-A.278), and sends the segments to the input 
mailbox for the INPUT TASK (A.287, A.294, A. 302). 

The SUPERVISOR TASK’S background duties are to 
check its input mailbox for a segment from the OUT- 
PUT TASK and to check a return mailbox for an abort 
request from the operator (A. 55 8, A. 225 -A. 268). If 
segments are received at the SUPERVISOR TASK mail- 
box, the SUPERVISOR TASK sends the segments on to 
the INPUT TASK if the operator has chosen continuous 
runs (A.258). Otherwise, the SUPERVISOR TASK de- 
letes the segments (A.242-A.250). When all the 
segments have been deleted, which halts the FFT 
analysis, the SUPERVISOR TASK asks for operator in- 
put again (A. 556). 

If an operator abort request is received, the SUPER- 
VISOR TASK, having higher priority than the FFT or 
OUTPUT TASKS, waits at their mailboxes to intercept 
the frame segments (A. 243, A. 249, A.207-A.224). 
When a segment is received it is deleted (A. 2 19). The 
SUPERVISOR TASK also checks the INPUT TASK 
mailbox under abort conditions (A. 244). This mailbox 
is FIFO based to allow the SUPERVISOR TASK to in- 
tercept the buffer segment ahead of the higher-priority 
INPUT TASK (A.523). The SUPERVISOR TASK in- 
put mailbox is also checked for frame buffer segments 
that may have been sent there by the OUTPUT TASK 
after the abort was requested (A. 246). When all of the 
frame buffer segments have been deleted, the SUPER- 
VISOR TASK asks for operator input (A. 556). 

INPUT TASK 

Listings of the INPUT TASK are in Appendix B. After 
initializing the buffer for Terminal Handler communi- 
cations and the mailboxes for communicating with the 
INTERRUPT TASK and the Terminal Handler (B.335, 

B. 302-B.333), the INPUT TASK waits at its input mail- 
box for a frame buffer segment (B.338). 

When a frame segment is received, the INPUT TASK 
updates the frame number counter kept by the INPUT 
TASK (B.340, B.289-B.301), and samples the analog in- 
put (B.341, B.231-B.288). The INPUT TASK selects 
one of two input driver routines, either a software poll- 
ing loop for faster sampling rates (B.277-B.281), or an 
INTERRUPT TASK for slower sampling rates 
(B.251-B.276). If the sampling is driven by interrupts 
and a Nucleus system call is executing at the time of the 
interrupt, the time required to respond to that interrupt 
can vary from 100 to 350 microseconds, depending on 
the Nucleus call in progress. For the sample rates of 391 , 
78, and 39 microseconds, corresponding to bandwidths 
of 1200, 6000, and 12,000 Hz, the system interrupt 
latency cannot guarantee the precise sampling interval 
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required. A a simple software polling loop with a delay 
between samples is used for these rates (assembler code 
for this loop is included after the INPUT TASK listings 
in Appendix B). This loop operates at priority 0, the 
highest priority, to guarantee the loop is not interrupted 
(B.278, B.280) while the sampling is in progress. 

For the longer intervals of 3.9 milliseconds and 781 
microseconds, corresponding to bandwidths of 120 and 
600 Hz, an Interrupt Handler and and INTERRUPT 
TASK are used (B.251-B.276). Under the iRMX 86 
Operating System architecture, an Interrupt Handler is 
defined as a short procedure with a primary goal of fast 
interrupt response and limited Nucleus calls. All hard- 
ware interrupt levels are masked when an Interrupt 
Handler is responding to an interrupt. If the interrupt 
servicing requires higher-level system functions, the In- 
terrupt Handler notifies a waiting INTERRUPT TASK. 
Higher-level interrupts are enabled when an INTER- 
RUPT TASK is executing. INTERRUPT TASKS can 
make all system calls. 

The INTERRUPT TASK (B.196-B.203) binds the In- 
terrupt Handler to the hardware interrupt level (B.197) 
and waits for a signal from the Interrupt Handler 
(B.199). The Interrupt Handler (B.164-B.195) verifies 
the interval accuracy (B.166-B.173), samples the data 
(which automatically starts the next sample) (B.175- 
B.176), places the data in the frame buffer (B.181- 
B.184), and notifies the INTERRUPT TASK when the 
frame buffer is full (B.193). If the buffer is not full, the 
Interrupt Handler resets the interrupt hardware (B.194). 
The INTERRUPT TASK notifies the INPUT TASK 
(B.200) and waits for a return message (B.201). The IN- 
PUT TASK disables interrupt level 3 (B.274) and re- 
turns the token to the INTERRUPT TASK (B.275). The 
INTERRUPT TASK enables the Interrupt Handler 
(B.199), but no interrupts will be received from the free- 
running 8253 Timer because hardware interrupt level 3 
has been disabled. Sampling for the next buffer is in- 
itiated by simply enabling level 3 (B.272). The INPUT 
TASK sends a status message to the Terminal Handler 
(B.342, B.219-B.230) and sends the filled frame buffer 
to the FFT TASK (B.343). The INPUT TASK then 
returns to the INPUT TASK input mailbox to wait for 
the next frame segment (B.338). 

FFT TASK 


is the final one to be averaged, the FFT TASK sends the 
frame buffer to the OUTPUT TASK. If the frame buf- 
fer is not the final one in this averaging series, the FFT 
TASK checks to see if the sampling process is continu- 
ous. if so, the frame buffer is returned to the INPUT 
TASK. If the sampling process is not continuous and 
the buffer is within two frames of the final frame buf- 
fer, the buffer is returned to the SUPERVISOR TASK 
to prevent unnecessary buffers from going to the IN- 
PUT TASK. The FFT TASK then returns to its input 
mailbox to wait for the next frame buffer. 

OUTPUT TASK 

Listings for the OUTPUT TASK are not included in this 
application note. The OUTPUT TASK, like the other 
tasks, waits at its input mailbox for a buffer. When a 
frame buffer is received from the FFT TASK, the OUT- 
PUT TASK stores the data in an internal buffer and 
sends the frame buffer to the SUPERVISOR TASK. 

The OUTPUT TASK converts each 32-bit frame buffer 
value to one of 16 levels by taking the base 2 logarithm 
of the significant 16 bits of sample value. The display 
screen is sent to the Terminal Handler one line at a time. 
Each line of the display is composed of 7 characters of 
label and y-axis data and 64 characters of display data 
(reference Figure 11). Each line of the display represents 
a power of two (from 16 down to 1). The character to be 
displayed at each location is found by comparing the ap- 
propriate sample value against the current line value. If 
the sample value is greater than the line number, a 
pound sign is displayed at that location. Otherwise, a 
space is displayed. The x-axis and labels are sent after 
the data lines to complete the display. The OUTPUT 
TASK then waits at its input mailbox for another frame 
buffer. 

TERMINAL HANDLER 

The Terminal Handler interfaces to the application 
tasks via the two mailboxes and buffer segment format 
shown in Figure 12. If a task wishes to display data, a 
segment containing the data is sent to the RQ$TH$- 
NORMSOUT mailbox, specifying a return mailbox. 
The Terminal Handler displays the data, updates the 
status fields, and sends the segment to the return 
mailbox. 


Listings for the FFT TASK are not included with this 
application note. The FFT TASK is similar in overall 
format to the INPUT TASK. The FFT TASK waits at 


Its inpUu maiiuox lor a irame uUner segmenL irom luc 
INPUT TASK. When one is received, the FFT TASK 
computes the fast Fourier transform of the data. The 
auto power spectrum is computed and averaged with 
previous data. The FFT TASK sends its status message 
to the Terminal Handler for display. If the frame buffer 


Input proceeds in much the same fashion. A task 
requesting data sends a segment to the 
RQ$TH$NORM$IN mailbox, again specifying a return 
mailbox. When the operator terminates the input line 
with a carriage return, the Terminal Handler puts the 
data in the segment, updates the status fields, and sends 
the segment to the return mailbox. This serves two 
primary purposes: specifying return mailboxes allows 
multiple tasks to share the display screen while retaining 
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Figure 12. Terminal Handier Interface 


synchronization and control over their data buffers; and 
a user- written Terminal Handler using the same pro- 
tocol and mailbox names could easily be integrated into 
the application. For this application, the INPUT TASK, 
FFT TASK, OUTPUT TASK, and SUPERVISOR 
TASK all share the screen for output, but only the 
ST TPFRVTSsOR TASR iicpc thp Terminal Handler to ob- 
tain operator input. 

Nucleus Calls 

The iRMX 86 Nucleus provides a comprehensive set of 
61 system calls. A complete description of these calls 
may be found in the iRMX 86 Nucleus Reference 
Manual. For most applications, only a subset of the 61 
calls will be required. The iRMX 86 Nucleus is configur- 
able, which means the final system Nucleus will contain 
code only for the system calls required for the applica- 
tion. In this case, the following system calls were 
required: 

RQ$CREATE$MAILBOX, RQ$SEND$MESSAGE, 
and RQ$RECEIVE$MESSAGE provide mailbox man- 
agement. 

RQ$CREATE$SEGMENT and RQ$DELETE$SEG- 
MENT are used to create and delete segments for the 
frame buffers, internal buffers, and Terminal Handler. 

RQ$SET$INTERRUPT, RQ$EXIT$INTERRUPT, 
RQ$SIGNAL$INTERRUPT, RQ$WAIT$INTER- 
RUPT, RQSENABLE, and RQ$DISABLE allow the 
INPUT TASK to handle hardware interrupts knowing 
only the hardware interrupt level (3). 

RQ$CREATE$JOB, RQ$CREATE$TASK, and 
RQ$SET$PRIORITY are used to create the jobs and 
tasks, and set the priority of the input polling loop. 

RQ$GET$TASK$TOKENS, RQ$LOOKUP$OBJECT, 
RQ$CATALOG$OBJECT, RQ$DISABLE$DELE- 


TION, RQ$ENABLE$DELETION, RQ$GET$TYPE, 
RQ$GET$PRIORITY, RQ$GET$SIZE, and RQ$SIG- 
NAL$EXCEPTION are system calls required by the 
Debugger and the Terminal Handler. None of these 
calls are necessary in this application if a user-written 
Terminal Handler is used and debugging is completed. 

System Configuration 

System Configuration is the integration step in the 
development process. It consists of selecting the por- 
tions of the iRMX 86 Operating System required in the 
application, mapping this code and the application code 
to system memory, and creating a Root Job that will in- 
itialize the system. The overall configuration process is 
shown in Figure 13. Configuration requires knowledge 
of available memory, operating system and application 
code entry points, priorities, exception handlers, and 
other system parameters. System Configuration consists 
of the following steps: 

1) Selecting the portions of the iRMX 86 Operating 
System required by the application, including the 
layers and the specific system calls in each layer. 

2) Linking and locating those portions. 

3) Assembling or compiling, linking, and locating the 
application code. 

4) Creating a configuration file that will tell the Nucleus 
the locations of available RAM memory, initial char- 
acteristics of each system job, and pertinent overall 
system parameters. Each job in the system has an en- 
try in the configuration file. The order of the entries 
is the order of initialization of the jobs. 

5) Creating the Root Job by assembling, linking, and 
locating the configuration file. 
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Figure 13. System Configuration Process 


During development of an EPROM-based application 
such as this one, configuration is accomplished twice: 
once for the RAM-based development system and once 
for the final EPROM-based system. These configura- 
tions are detailed in Appendix C, System Configura- 
tion. In both cases, the Root Job that results from con- 
figuration initializes the system jobs. For development, 
the system job structure is shown in Figure 7. The Root 
Job creates the Debugger Task in the Debugger Job, 
which in turn creates the Terminal Handler Task. The 
Root Job then creates the SUPERVISOR TASK, which 
creates the INPUT TASK, FFT TASK, and OUTPUT 
TASK. The INPUT TASK creates the INTERRUPT 
TASK when necessary. 

Software development is completed on the iSBC 86/12A 
Single Board Computer discussed earlier in this note. 
After application code is debugged and ready to be 
placed in EPROM memory, the Debugger Job, which 
contains both the Debugger and the Terminal Handler, 
is removed and replaced with the Terminal Handler 
Job, which contains only the Terminal Handler. This 
job structure is shown in Figure 8. The Nucleus system 
calls required only by the Debugger are removed from 
the iRMX 86 Nucleus. The application code is not 
changed. The application code and the iRMX 86 
Nucleus is configured for the final system, put in 
EPROM memory, and tested on the final hardware sys- 
tem. The final Nucleus and application code required 
30. 5K bytes of EPROM, allowing room for future code 
changes and some expansion within the 32K system 
limit. 

The final application hardware is shown in Figure 14. 
This system contains an iAPX 86/10 CPU, an 8259A 
Programmable Interrupt Controller, and an 8253 Pro- 


grammable Timer. The three chips form the primary 
hardware requirements for the iRMX 86 Operating Sys- 
tem. The system is assembled from Intel components, 
using standard support circuits and system schematics 
described in Intel documentation. The analog sampling 
circuitry is a 12-bit analog to digital converter (ADC) 
and a sample/hold circuit. Both the sample/hold circuit 
and the ADC are driven from the on-board local bus. 
The ADC has a conversion time of 35 microseconds, 
limiting the overall cycle to approximately 39 micro- 
seconds per sample, or a maximum CRT display band- 
width of 12,000 hz. 


The hardware system shown in Figure 14 contains com- 
ponents not specifically required for the final configura- 
tion. The 8255A Programmable Peripheral Interface 
and the MULTIBUS multimaster interface are not nec- 
essary for a system limited to just spectrum analysis and 
display via the CRT. However, the flexibility advan- 
tages of the iRMX 86 Operating System are supported 
by this hardware. For instance, the frequency spectrum 
display is limited by the CRT to a 16-level logarithmic 
approximation. Accuracy could be improved by using 
the programmable peripheral interface to drive a plotter 
or an analog CRT via a digital to analog converter. 
Software drivers for the plotter or CRT could be new 
tasks, interfacing to the old tasks through the mail- 
boxes. Or, the OUTPUT TASK could be simply re- 
placed with a new OUTPUT TASK for the plotter and 
analog CRT. The inclusion of the MULTIBUS interface 
allows this application to be integrated into a larger 
system of MULTIBUS-compatible boards. M^ULTI- 
BUS-compatible memory boards will also aid test and 
debug. Users of hardware components can include these 
modular Intel interfaces as required by their applica- 
tion, giving growth and configurability in both hard- 
ware and software. 
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Figure 14. Final Hardware System Block Diagram 


SUMMARY 

This application note discussed general operating sys- 
tem functions, the Intel iRMX 86 Operating System, 
using the iRMX 86 Operating System on hardware com- 
ponent systems, and an example of an application im- 
plemented in a component environment. Users of the 
iRMX 86 Operating System are able to simplify applica- 
tion code development through modularity, standard 
interfaces, freedom from rigid hardware restrictions, 
and advanced debugging techniques. The iRMX 86 
Operating System can be applied to larger systems by 
adding other iRMX 86 layers, making the software in- 
vestment beneficial over a wide range of applications. 

Operating systems provide many advantages for hard- 
ware component designs, but all of these benefits can be 
utilized only if the operating system and the develop- 
ment environment are fully supported. Intel’s support 
for this application begins with an Intel MDS 230 Series 
II Microcomputer Development System. The MDS 230 
System interfaces with the development hardware 
through the iSBC 957A™ Monitor. The development 
hardware is an Intel iSBC 86/12A Single Board Com- 
puter, an Intel iSBC 711™ Analog Input Board, an Intel 
iSBC 032™ 32K RAM Memory Board, an Intel iSBC 
064™ 64K RAM Memory Board, and an Intel iSBC 
660™ System Chassis. Final application hardware is de- 
bugged using Intel’s ICE-86™ 8086 In-Circuit Emu- 
lator. Software support is provided by the ISIS-II 


PL/M 86™ Compiler, MCS-86™ Macro Assembler, 
and the MCS-86 Utilities LINK86, LOC86, and OH86. 
The Intel UPP-103™ Universal PROM Programmer is 
used to convert the final system to PROM memory. 
This broad support allows expedient development of 
prototype and final systems based on the iRMX 86 
Operating System. 

The iRMX 86 Operating Systems and the Intel develop- 
ment tools are valuable only if they translate directly to 
increased productivity and shortened time to market for 
new products. This application has 1567 lines of appli- 
cation code. It was developed, from design to final im- 
plementation, in approximately 9 man-weeks of effort. 
This high level of productivity was achieved with the 
added benefits of modularity, standardization, and ease 
of application growth. 

Intel Corporation is committed to both the continued 
integration of higher-level functions into hardware and 
to maintaining compatibility of present software with 
new hardware. One result of these commitments will be 
the Intel iAPX 86 and iAPX 286 Processors, which will 
be compatible with the iRMX 86 Operating System. 
Another result will be the placement of the iRMX 86 
Operating System Nucleus into hardware. This will 
allow custom hardware applications to have higher-level 
functions, simplified development, and decreased chip 
count. Using the iRMX 86 Operating System today will 
give hardware component users a headstart on Intel’s 
technological innovation for tomorrow. 
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PL/M-S6 COMPILER SUPERVISOR TASK FOR AP NOTE 110, OCTOBER 1980 
ISIS-II PL/M-86 V2.0 COMPILATION OF MODULE SUPERVI SOR_MODULE 
OBJECT MODULE PLACED IN : FI : supe rv . OB J 
COMPILER INVOKED BY: plmS^S : FI : superv .p8<S 

StitleC SUPERVISOR TASK FOR AP NOTE 110, OCTOBER 1980') 
$large debug 
SUPERVISOR_MODULE : 
do ; 

$ incl ude ( : f 1 : nucl us , ext ) 

= $SAVE NOLIST 


089 1 


declare token literally 'word'; 


y************************************************y 

/* The six mailboxes immediately following will */ 
/* form all of the inter-task communications */ 
/* interfaces for the five tasks that run in */ 
/* this system. */ 


090 

1 

declare 

th in mbx 

token 


091 

1 

declare 

th out mbx 

token 


092 

1 

declare 

to input mbx 

token 

publ ic ; 

093 

1 

declare 

to fft mbx 

token 

publ ic ; 

094 

1 

declare 

to output mbx 

token 

public; 

one 

1 

4^ 1 V 


4“ Ir r> 


096 

1 

declare 

return th in mbx 

token 


097 

1 

declare 

return th~ouE mbx 

token 


098 

1 

declare 

dummy mbx 

token 


099 

1 

declare 

frame segment one 

token 


100 

1 

decla re 

frame segment two 

token 


101 

1 

declare 

frame segment three 

token 


102 

1 

declare 

th in segment token 

token 


103 

1 

declare 

th out segment token 

token 


104 

1 

declare 

general index 


byte ; 

105 

1 

declare 

number of fft data segments 

; byte; 

106 

1 

declare 

insert text pointer 

pointer ; 

107 

1 

declare 

abort flag 

word 


108 

1 

declare 

status 

word, 


109 

1 

declare 

segment deleted tall;/ 

word, 


110 

1 

declare 

text length 

word 


111 

1 

declare 

root job token 

token 


112 

1 

declare 

input task token 

token 


113 

1 

declare 

fft task t^ken 

token 


114 

1 

declare 

output ta’sk token 

token 


115 

1 

declare 

parameters 

structure ( 


actual samples word. 
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actual interval word, 

f requency_answer ( 5) byte, 

ac tual_f rames to average word, 

f rames_to_ave'rage_answer ( 5) byte , 

continuous_f lag word, 

continuous flag answer(5) byte); 


116 

1 

declare 

117 

1 

declare 

118 

1 

declare 

119 

1 

declare 

120 

1 

declare 

121 

1 

declare 

122 

1 

declare 

123 

1 

declare 

124 

1 

declare 

125 

1 

declare 

126 

1 

declare 

127 

1 

declare 

128 

1 

declare 

129 

1 

declare 

130 

1 

declare 

131 

1 

declare 

132 

1 

declare 

133 

1 

declare 

134 

1 

declare 


abort 
asci i_9 

car r ia’ge_return 
forever 
1 ine_f eed 
new_7f t_run 
no_abort 

no_response_requested 

null 

queue_f i f o 
queue_pr ior i ty 
root j ob 

run continuous 
si z¥_120_bytes 
spac¥ ~ 
supervisor_job 
th_read 
th_wr i te 
wait forever 


literally 

• OFFH' ; 

literally 

' 039H ' ; 

1 i terally 

' ODH' ; 

literally 

'while 1 ' ; 

literally 

' OAH ' ; 

1 i terally 

' OFFH' ; 

literally 

' OOH' ; 

literally 

' OOH' ; 

literally 

'OOH'; 

literally 

'OOH'; 

literally 

' OlH' ; 

literally 

' 03H' ; 

literally 

' OFFFFH' ; 

literally 

'120'; 

literally 

'20H'; 

literally 

'OOH'; 

literally 

' OlH' ; 

literally 

' 05H' ; 

literally 

' OFFFFH' ; 


/* The following declaration sets the characters */ 
/* to send the cursor home at the beginning of */ 
/* each message to the display screen. The */ 
/* seqeunce is tilde, DC2 (Hazeltine) ) . */ 


135 1 

136 1 

137 1 

138 1 


139 1 

140 1 


declare cursor home chars(2) byte data ( 07EH, 012H, ) ; 


declare f rame_pointer pointer; 

declare f rame_pointer_values structure( 

offset word, 

base word) at (0frame pointer); 


declare frame based f rame_pointer 
samples_per_f rarne” 
sample interval 
f r ames~to_av e r ag e 
continuous_f lag 
thi s_f rame_number 
number_samples missed 
sample_po inter 
reset flag 
sample (256) 


structure ( 
wo rd , 
word , 
v;ord , 
word , 
word , 
word , 
word , 
word , 
integer) ; 


declare th_in_segment pointer pointer; 

declare th_in_segment pointer values structure( 
offset word, 

base word) at (@th in segment pointer) ; 


19 


APPENDIX A 


II 1101 


141 1 


142 1 

143 1 


144 1 


145 1 


146 1 


147 1 


148 1 


149 1 


150 1 


151 1 


declare 


declare 

declare 


declare 


declare 


declare 


declare 


declare 


declare 


declare 


declare 


th in_segment based th in segment pointer 


st7ucture( — — — 

function word, 

count word, 

except ion_code word, 

actual word, 

message(112) byte); 

th out segment pointer pointer; 


th~out~segment~po i nter_val ues structure ( 
offset word, 

base word) at (i?th_out_segment_pointer) ; 
th out segment based th out segment pointer 


structure ( — — — 
function word, 
count word, 
except ion_code word, 
actual word, 
home_chars ( 2) byte, 

1 ine_index ( 24) byte, 
message(84) byte); 


f requency_question ( *) byte data ('Please' 

' enter the highest frequency in Hz (120, 

' 600, 1200, 6000, OR 12000):'); 

f requency_answers_data ( * ) byte data (05H, 
03H, OSH, 04H, 04H, 05H, OH, 

' 120 600 1200 600012000 ' , 

42H,0FH, 00DH,03H, 087H,01H, 

4EH,00H, 027H,00H, 00H,000H); 

average_quest ion ( * ) byte data ('Please' 

' enter~the number of frames to average' 

' (1, 2, 4, 8, 16, OR 32) : ') ; 

average_answer s_data ( * ) byte data (06H, 

OlH, OlH, OlH, OlH, 02H, 02H, 

' 1 2 4 8 16 32', 

01H,00H, 02H,00H, 04H,00H, 

08H,00H, 10H,00H, 20H,O0H); 

continuous_quest ion ( *) byte data ('Please' 

' enter ’'i»' for one sample run or ''C'' 

' for continuous running:'); 

continuous_answers_data ( * ) byte data (OSH, 
OlH, OlH, OlH, OOH, OOH, OOH, 

' 1 C c 

OOH, OOH, 0FFH,0FFH, 0FFH,0FFH, 

OOH, OOH, OOH, OOH, 00H,00H); 

re j ect_message (*) byte data ('I cannot' 

' accept your answer. PLEASE TRY AGAIN.'); 
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152 

] 

declare 

status line one(*) 

byte data 

( ’ 

Cur rent ' 




’ settTngs are the 

following : 


frequency 




' range 0 to 

Hz, ' ) ; 



1 c; 

a. 

X 

d e c 1 a e 

c h ^ h a lino ¥ f "k \ 

hi\r¥ o A ^ ^ 

f » 

1 




' frames to average 

per output 

d i splay, ' 




' and 




154 

1 

declare 

continuous runs(*) 

byte data 






('continuous runs.' 

) ; 



155 

1 

declare 

single run(*) byte 

data 






( ' a single run . ' 

) ; 



156 

1 

declare 

go ahead question(* 

) byte data 

( 'If ' 




'these settings are 

correct. 

enter ' ' G ' ' 




'to begin running.' 

) ; 



157 

1 

declare 

header line one{*) 

byte data 

( ’ 

INTEL' 


’ APNOTE 110 — THE i RMX 86 OPERATING SYSTEM' 
' AND iAPX 86 COMPONENT DESIGNS.’); 


/* The following three procedure declarations */ 
/* link the tasks outside the SUPERVISOR MODULE */ 
/* with the supervisor task. */ 


158 1 

159 2 

160 1 
161 2 

162 1 
163 2 


164 1 

165 2 


INPUT_TASK: PROCEDURE EXTERNAL; 
END INPUT_TASK; 

FFT_TASK: PROCEDURE EXTERNAL; 
END FFT TASK; 


OUTPUT_TASK: PROCEDURE EXTERNAL; 
END OUTPUT TASK; 


^***********************************************y^ 

/** The following five procedures are general **/ 
/** utility procedures called by the primary **/ 
/** working procedures. **/ 
y********************** ******* ******************/ 


/* Blank_line just fills the message buffer */ 
/* with blank characters. */ 


BLANK_LINE: PROCEDURE; 

declare blank line index word; 
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16 ?^ 2 
1^7 3 

158 3 

169 2 

170 2 


171 1 

172 2 

173 2 

174 2 


175 1 

176 2 

177 2 

178 2 

179 2 

180 2 

181 3 

182 3 

183 2 

184 3 

185 3 

186 3 

187 2 

188 2 


do blank line_index = 0 to 78; 

th_out_segment .message (blank line_index) 
= space; ~ ~ 

end ; 


th_out_segment .message (79) = carriage return; 


END BLANK LINE; 


/* DISPLAY_LINE sends the message to the */ 
/* terminal handler output mailbox and */ 
/* waits for the segment to be returned. */ 

y/*****************************************y' 


DISPLAY_LINE: PROCEDURE; 

call rqSsendSmessage (th_out_mbx, 

th_out_segment_token , 
return_th_out_mbx , '^status); 
th_out_segment_token = rq$receive8message 

( return_th_out_mbx , 
wa i t_f orever , Odummy_mbx, 
^status ; ) 

END DISPLAY_LINE; 

y**************'**********************************y 
/* INSERT_TEXT fills the output message segment */ 
/* with the chosen message and pads the rest of */ 
/* the line with blanks. */ 

/************************************************/ 


INSERT_TEXT: PROCEDURE (TEXT_POINTER , H0VJ_MANY) ; 

declare text_pointer pointer; 

declare how_many word; 

declare dummy based text_pointer structure ( 
entries(SO) byte) ; 
declare insert text index word; 

do insert_text_index = 0 to (how_many - 1) ; 

th_out_segment .message ( insert_text_index) = 
dummy .entries ( insert_text~index) ; 
end ; ~ 

do while insert_text_index < 79; 

th_out_segment .message ( insert_text_index) 

= space; 

insert_text_index = insert_text_index + 1; 
end ; 

th_out_segment .message (79) = carr iage_return ; 
END INSERT TEXT; 
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189 1 

190 2 

191 2 

192 2 

193 2 

194 3 

195 3 

196 2 

197 3 

198 3 


/* Move_down_l ine puts the required number of */ 
/* line~feed~characters in the first 6th */ 
/* through 29th character of the output */ 
/* message. Each line is displayed on the */ 
/* screen in its proper location. This allows */ 
/* multiple tasks to access the screen */ 
/* without having to blank the line each */ 
/* time. This technique assumes each message */ 
/* sends the cursor home each time. */ 


M0VE_D0WN_LINE: PROCEDURE (SKI P_LINES ) ; 

declare skip_lines word; 

declare move down line index word; 

if skip_lines > 0 then 

do move_down_l ine_index = 0 to (skip_lines - 1); 
th_out’_segment . 1 ine_ijndex (move_down_l ine_index) 
= line_feed; 

end ; 


do move_down_l ine_index = skip_lines to 23; 

th out segment. line index (move down line index) 
= nuTl; ~~ — — — 

end ; 


199 2 


200 1 

201 2 
202 2 

203 2 

204 2 

205 2 

206 2 


END MOVE DOWN LINE; 


y'*******************'*****:SriSf*''****’*****^********x*y 

/* SEND_REJECT_MESSAGE is called by INPUT */ 
/* PARAMETERS. It just sends a reject message */ 
/* to the CRT to inform the user that the */ 
/* answer the user gave was not valid. */ 


SEND_REJECT_MESSAGE: PROCEDURE; 

call move down line (21); 

text length = si ze ( re j ect_message) ; 

inse7t_text_po inter = Ore j ect_mes¥age ; 

call insert~text ( insert_text_pointer , text_length) ; 
call display_line ; 

END SEND REJECT MESSAGE; 


/** The following procedures are the primary **/ 
/** working procedures called by the supervisor **/ 
/** procedure and its called procedures. **/ 

y^XXXXXXXXXXXXXX^XXXXXX*'*'*************************^ 

y************************* ************************/ 
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/* PURGE_MAILBOX removes all tokens from */ 
/* a mailbox. The purpose is to remove segments */ 
/* waiting for processing by one of the tasks */ 
/* if the operator has specified an abort */ 
/* request. If the segment deletion was */ 
/* successful, PURGE_MAILBOX updates the */ 
/* segment deleted tally. */ 


207 1 

208 2 

209 2 

210 2 

211 2 
212 2 

213 2 

214 2 

215 2 

216 3 


217 3 

218 3 

219 4 

220 4 

221 4 

222 4 

223 3 

224 2 


225 1 


PURGE_MAILBOX: PROCEDURE (MAILBOX_TO_PURGE) ; 

declare mai lbox_to_purge token; 

declare for_l 10_mi 11 iseconds literally 'OBH'; 
declare message received literally 'OH'; 


declare contents_token 
declare purge_dummy_mbx 
declare purge status 


token ; 
token ; 
token ; 


purge status = message received; 


do while purge_status = message_received ; 
contents_token = rqSrecei veSmessage 

(mai lbox_to_purge , for_110_mill iseconds , 
(annrnp dnmmv mhx . ®nnrap status^ r 


if purge_status = message_rece i ved then 
do ; 

call rq$delete$segment 

(contents_token , 0purge_status) ; 
segment_deleted_taTly = 

segment deleted tally + 1; 
purge_status = message_rece i ved ; 
end ; 

end ; 


END PURGE MAILBOX; 


y'***********************************************y 


/* M0NIT0R_MAILB0XES polls the */ 
/* return_th_in_mai Ibox and the */ 
/* to_superviso7_mailbox for messages. The */ 
/* messages will~be abort (from the operator), */ 
/* and FFT done or OUTPUT done if the runs are */ 
/* not continuous. If the runs are not */ 
/* continuous and an FFT done message is */ 
/* received, MONITOR_MAILBOXES will initialize */ 
/* the OUTPUT task. “ */ 


MONITOR MAILBOXES: PROCEDURE; 
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226 

2 

declare 

cannot wait 

1 i teral ly 

' OOH ' 

i 

227 

2 

declare 

done 

literally 

' OFFH* 

228 

2 

declare 

for 400 milliseconds 

literally 

' 28H ' 

t 

229 

2 

declare 

message~recei ved 

literally 

' OOH ' 

/ 

230 

2 

declare 

not done 

literally 

' OOH ' 

f 

231 

2 

declare 

monitor dummy mbx 

token ; 



232 

2 

declare 

monitor token 

token ; 



233 

2 

declare 

monitor status 

token ; 



234 

2 

declare 

done flag 

byte ; 



235 

2 

declare 

monitor index 

word ; 



236 

2 

done fl. 

ag = not do 

ne ; 



237 

2 

segment 

deleted tally = 0; 




238 

2 

call rq$send$message 





(th in_mbx, th in_segment token, 
return th in mbx , ^status) ; 


239 2 do while done flag = not done; 

/* Check foF operator input here. */ 

240 3 moni tor_token = rq$ rece i veSmessage 

( return_th_in_mbx , for_4 0 0_mi 1 1 i seconds , 
Omoni tor_dummy_mbx , f?Tnoni'tor_status) ; 

241 3 if moni tor_status = message_received then 

242 3 do whi le~segment_deleted_t’al ly < 

number_o f_f f t_data_segments ; 

243 4 call purge_mai Ibox (to_fft_mbx) ; 

244 4 if segment_deleted_tal ly < 

number_of fft data segments then 

245 4 call purge mailbox (to input mbx) ; 


246 

4 

if segment deTeted tally Z ~~ 

number of. fft dat"a segments then 

247 

4 

call purge mailbox (to supervisor mbx 

248 

4 

if segment deleted tally < 

number of” fft da¥a segments then 

249 

4 

call purge mailbox (to output mbx) ; 

250 

4 

done flag = done; 

251 

4 

end ; 

252 

3 

if done flag = not done then 

253 

3 

1 

1 

o 

'O 

254 

4 

monitor token = rq$receive$message 

(to supervisor mbx, for 400 milliseconds 
^monitor dummy mbx, ^monitor status); 

255 

4 

if monitor status = message received then 

256 

4 

do; ~ 

257 

5 

if parameters .continuous flag = 
run continuous then 

258 

5 

call rq$send$message 


( to_input_mbx , moni tor_token , 
no_r esponse_requested , 
^monitor status) ; 


else 
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259 5 

250 6 

261 6 

262 6 


264 6 

265 5 

266 4 

267 3 

268 2 


269 1 

270 2 

271 2 

27 2 2 

273 2 

274 2 

275 2 

276 2 

277 2 

278 2 


279 1 

280 2 
281 2 
282 2 

283 2 

284 2 


do ; 

call rq$delete$segment 

(moni tor_token , flmoni tor_status) ; 
segment deleted_tal ly ~ 

= segment deleted_tally + 1; 
if segment_deleted_tal ly 

= number_of_f f t_data_segments 
then done_fTag = done; 
end ; ~ 

end ; 

end ; 

end ; 

END MONITOR MAILBOXES; 


/* SET_SEGMENT initializes the common parameter */ 
/* areas of the segment. The pointer to the */ 
/* proper segment is set up by */ 
/* INITIALIZE SEGMENTS. */ 


SET_SEGMENT: PROCEDURE; 

frame .samples_per_frame = 128; 
frame . sample_interval 

frame . frames_to average 

= parameters . act ual_frames_to_ave rage ; 
f rame .continuous_f lag = parameters .continuous flag; 

frame . thi s_frame_number = OOH; 

frame .number_samples_missed = OOH; 

frame . sample_poi nter~ = OOH; 

frame. reset flag = OOH; 


END SET SEGMENT; 


/************************************************ y 
/* INITIALIZE_SEGMENTS creates the three FFT */ 
/* data segments and calls SET_SEGMENT for each */ 
/* segment to initialize the common parameter */ 
/* areas of the segments. */ 


INITIALIZE_SEGMENTS : PROCEDURE ; 

declare si ze_528_bytes literally '528'; 

f rame_pointer_values .off set = 0; 

f rame_segment_one = rq$create$segment 

( si ze_528__bytes , Ostatus) ; 
f rame_pointer_values .base = f rame_segment_one ; 

call set segment; ~ 
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285 2 

286 2 

287 2 


288 2 

289 2 

290 3 

291 3 

292 3 

293 3 

294 3 


295 3 


f rame . reset__f lag = new fft run; 

nuinber_of_f f t_data_segments = 1; ~ 
call rq$send$message 

( to_input_mbx , f rame_segment_one , 
no_response_requested , Psta'Eus) ; 

if parameters . actual_frames_to_average > 1 then 

do ; 

f rame_segment_two = rq^crea te$segment 

(si ze_528_bytes , Ostatus) ; 
f rame_pointer_values .base = f rame_segment_two ; 
call set_segment; 
number_of_f f t_data_segments = 2; 
call rq$send$message 

( to_input_mbx , f rame_segment_two , 
no_response_requested , Pstat^us) ; 

end ; 


296 2 

297 2 

298 3 

299 3 

300 3 

301 3 

302 3 


303 3 

304 2 


if parameters ,actual_frames_to_average > 2 then 
do ; 

f rame_segment_three = rqScrea te$segment 
~(si ze_528_bytes , ^status) ; 
f rame_pointer_values .base 

= f rame_segment_three ; 

call set_segment; 

number_of_f f t_data_segments = 3; 

call rq$s¥nd$message 

( to_input_mbx , f rame_segment_three , 
no_response_requested , Sstarus) ; 

end ; 

END IMITIALIZE_SEGMENTS; 

y'************************* ********** ************/ 


/* INPUT_PARAMETERS contains three procedures: *'/ 
/* set_question_po inters , get_answer, */ 
/* and ver i fy_answers . The INPUT_PARAMETERS */ 
/* loop consists of calls to these three */ 
/* procedures and, as usual, exists at the end */ 
/* of the procedure. */ 


/***********************************************/ 


305 1 INPUT PARAMETERS: PROCEDURE; 


3 

3 

3 

3 

3 




06 

2 

declare 

07 

2 

declare 

08 

2 

declare 

09 

2 

declare 

10 

2 

declare 


actual pointer 

pointer ; 

answer pointer 

pointer ; 

answer display pointer 

pointer; 

question pointer 

pointer; 

answer actual value based 

actual pointer word; 

answer pointer 

structure ( 

number of answers 

byte , 
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312 2 


313 2 

314 2 

315 2 

31<S 2 

317 2 

318 2 

319 2 

320 2 

321 2 

322 2 

323 2 

324 2 

325 2 

326 2 

327 2 

328 2 

329 2 

J JU l 
331 3 


declare 


declare 

declare 

declare 

declare 

declare 

declare 

declare 

declare 

declare 

declare 

declare 

declare 

declare 

declare 

declare 

declare 

declare 


leng th_of_answer ( 6 ) byte, 
values_to_match ( 30) byte, 
real ly_are ( 6 ) word) ; 

answer_display based 

answer_dis.play_po inter structure ( 
characters ( 5) byte) ; 


answer_byte_index byte 
answer_index byte 
answer_match byte 
byte_match byte 
input_byte_index byte 
output_byte_index byte 
quest i^n_number byte 
stop byte byte 


asc i i_smal l_g 
asc i i_capi tal_G 
average_ent ry_po int 
continuous_ent"ry_point 
f requency_entry_po int 
match ~ 

no_match 
not_negati ve 
nothing returned 


literally ' 067H ' ; 

1 iterally ' 047H ' ; 
literally * 0 ' ; 
literally ' 48 ' ; 

1 i teral ly ' 58 ' ; 
literally 'OFFH'; 
literally ' OOH ’ ; 
literally '< 255'; 
1 i teral ly ' OOH ' ; 


set question pointers: procedure; 


do case question number; 


332 4 

333 5 

334 5 

335 5 

336 5 

337 5 

338 5 


do; 

text_length = size ( f requency_quest ion) ; 

quest ion_pointer = Of requency_ques’t ion ; 
answer_pointer = Of requency_answers_data ; 
actual_po inter = Oparameters . actual_interval ; 
answer_display_pointer ~ 

= Oparameters , f requency_answer ; 
end ; ~~ 


339 4 

340 5 

341 5 

342 5 

343 5 

344 5 

345 5 


do ; 

text_length = size (average_question) ; 

question_pointer = Oaverage_ques’t ion ; 
answer_pointer = Oaverage_answers_data ; 
actual_pointer ~ 

= Oparameters . act ual_frames_to_ave rage ; 
answer_d i splay_po inter 

= Oparameters . f rames_to_average_answer ; 

end ; 


346 4 

347 5 

348 5 

349 5 

350 5 


text_length = size (continuous_question) ; 

quest ion_pointer = Ocontinuous_question ; 
answer_pointer = Ocontinuous_answers_data ; 
actual_po inter = Oparameters .continuous flag; 
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351 5 answer_display_po inter 

= 0 parameters .continuous_f lag_answer ; 
35 2 5 end; ~ ~~ 

353 4 end; 

354 3 end set question pointers; 


355 2 


355 3 

357 3 

358 3 


359 3 

360 3 

361 3 


362 3 


363 3 


364 3 


365 3 


367 3 

368 4 


369 4 


get_answer: procedure; 

/* First display the question to be answered */ 

/* by the operator. */ 

call insert_text (question_pointer , text length); 
call move_down line (19); ~ 

call d isplay_lTne ; 

/* Then blank the line below for an answer line. */ 

call blank line; 

call move_d^own_l ine (20); 

call d isplay_l ine ; 

/* Now wait for a response from the operator. */ 

call rq$send$message 

(th_in_mbx, th_in_segment_token , 
return_th_in_mbx7 ^status’) ; 
th_in_segment_token = rq$receive$message 

( return_th_in_mbx , wait_forever , 
0dummy_mbx, (^status) ; ~ 
th_in_segment_pointer values .base 

= th_Tn_segment_token ; 

/* If there is no message returned then send */ 

/* a reject message. */ 

if th_in_segment . actual = nothing_returned 
then call send_reject message; ~ 

/* Otherwise it is time to check the response */ 

/* against the possible answers. */ 

else 
do ; 

answer_match = no_match; 

/* Set the number of possible answers. */ 
answer_index 

= answer_over lay . number_of_answers ; 

/* Start a loop to check all of the */ 

/* possible answers. */ 
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370 4 


371 5 


372 5 


373 5 


374 5 

375 5 

376 6 

378 7 

380 7 

381 7 

382 6 

383 6 

384 6 

385 6 


386 5 

387 5 


do while (answer_match = no_match) and 
(answer~index > 0) ; 

/* Set the starting point for the */ 

/* byte by byte compare. */ 

answer_byte index = (answer_index * 5) - 1; 

/* Set the stopping point for */ 

/* the compare. */ 

stop_byte = answer_byte_index 

- answer_overlay . length_of_answer 
( answer_index - 1) ; 

/* Start with a "match" so we can */ 

/* check until "no match" occurs. */ 


byte match = match; 


/* 

Set sta 

rting point at 

the 

right end 

*/ 

/* 

of the 

input data (al 

lows 

us to 

*/ 

/* 

ignore 

leading blanks 

and 

the 

*/ 

/* 

ending 

carriage retur 

n) . 


*/ 

input byte 

index = th in 

segment. actual 

-2; 

/* 

Scan th 

e bytes until 

all 

pertinent 

*/ 

/* 

ones ar 

e checked or a 

" no 

match" 

*/ 

/* 

occurs . 




*/ 


do while (byte_match = match) and 

( answ¥r_byte_i ndex > stop_byte) ; 
if ( input_byte~inde¥ not_nega t i ve) 
then do; 

if th_in_segment .message 
( input_byte_index) = 
answer_overlay . val ues_to_match 
(answer_byte_index) 

then byte_match = match; 
else byte_match = no_match; 
end ; 

else byte_match = no match; 

answer_byte_index = answer_byte_index-l ; 
input_byte_index = input_byte_index -1; 
end ; 

/* A "match" at this point means ALL */ 

/* bytes matched. */ 

if byte_match = match then 

do ; 

/* Set real values via */ 
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388 6 


389 6 


390 6 

391 6 

392 6 

393 7 


394 7 

395 7 

396 7 


397 6 

398 6 

399 6 

400 6 


401 5 

402 5 


403 4 


405 4 

406 5 

407 5 


1 ) 


/* answer_actual_val ue overlay, */ 

answe r_actual_val ue 

= answer_over lay . real ly are 
( answe r_index - 1); ~ 

answe r_match = match; 

/* Insert displayable values for */ 

/* later display. */ 

answer_byte_index = 4; 
input_byte_index = (answer_index*5) -1 ; 

do while answe r_byte_index not negative; 
answer_di splay .characters” 

( answe r_byte_ind ex) 

= answer_overlayTvalues_to_match 
( input_byte_index) ; 
input_byte_index ~ 

- input_byte_index - 1; 
answe r_byt¥_ind ex 

= answe r_byte_ind ex - 1; 
end ; ~ 


/* We got a match, so be sure the */ 
/* reject message line is blanked. */ 

call move_down_l ine (21); 
call blank_line; 
call display line; 
end ; ~ 


/* If no match, then let's compare the */ 
/* input with the next possible answer. */ 


else answer_index = answer_index - 1; 

end ; 

/* If we got a match, then we can move on */ 

/* to the next question. */ 

if answer_match = match 

then quest ion_number = quest ion_number + 1; 

/* Otherwise we have to check for an */ 

/* abort request of '99'. */ 


else 
do ; 

input_byte index = th_in_segment .actual-2; 
i f ( th_in_segment .message ( input_byte_index) 
= ascii_9) 

and 

( th_in_segment .message ( input_byte_index - 
= ascii 9) then 
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408 5 

409 ^ 

410 6 

411 6 

412 6 

413 6 


414 5 

415 5 

416 4 

417 3 


/* Abort requests are valid, so blank */ 
/* the reject message line and reset */ 
/* the question number so we start */ 

/* asking all over. */ 

do ; 

quest ion_number = 1; 
call move_down_l ine (21); 
call blank_line; 
call display_l ine ; 

end ; 
else 

/* But if nothing matched and the */ 

/* answer was not an abort request, */ 

/* then we have to ask the operator */ 

/* to try again on this question. */ 

call send_re j ec t_message ; 

end ; 

end ; 

end get answer; 


418 2 


419 3 

420 3 


ver i f y_answers : procedure; 

/* First put the output line in the buffer. */ 

text_length = size ( sta tus_l ine_one) ; 

call insert text ((^status line one, text length); 


421 3 

422 3 

423 3 

424 4 

425 4 

426 4 

427 3 

428 3 


429 3 

430 3 


/* Then insert the displayable frequency answer. */ 
input_byte_index = 0; 

stop byte ~ = f requency_entry_point + 4; 

do oTJtput_byte_index 

= f requency_entry_po int to stop_byte; 
th out segment .message (output_byte_index) = 
parameters . frequency_answer ( input_byte_i ndex) ; 
input_byte_index = input_byte_index + 1; 
end ; ~ 

call raove_down_l ine ( 19) ; 
call display_l ine ; 

/* We have sent the first line, now it is time */ 

/* to get the second line. */ 

text_length = size ( status_l ine_two) ; 

call insert text (@status_l ine_two , text_length) ; 

/* We have to insert the displayable "frames */ 
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/* to average" answer, */ 

431 3 input_byte_index = 0; 

432 3 stop_byte = aver age_ent ry_po i nt + 4; 

433 3 do output_byte_index ~ 

= average_entry_point to stop_byte; 

434 4 th_out_segment .message (output_byte_index) = 

parameters . f rames_to_average_answ¥r 
( input_byte_index) ; 

435 4 input_byte~index = input_byte_index + 1; 

436 4 end; 

/* The continuous answer is d i f f erent--we have */ 

/* to decide if we have continuous runs or */ 

/* single runs, and insert those words in the */ 

/* display line. */ 

437 3 input_byte_index = 0; 

438 3 stop_byte = continuous_entry_point + 15; 

439 3 if parameters .continuous flag = run continuous 

then ~ ~ 

440 3 do output_byte_index 

= continuous entry point to stop byte; 

441 4 th_out_segment .message {output byte index) = 

cont inuous_runs ( input_byte_TndexY; 

442 4 input_byte_index = inpuE_byte_index + 1; 

443 4 end; ~ ~ ~ 

else 

444 3 do output_byte_index 

= continuous_entry_point to stop_byte; 

445 4 th_out_segment .message (output byte index) = 

single_run ( input_byte_indexY; ~ 

446 4 input_byte_index = input_byte_index + 1; 

4 47 4 end; ~ ~ ~ 

/* Then send the message and wait for a response */ 
/* from the operator. */ 

448 3 call move_down_l ine ( 20 ) ; 

449 3 call d i splay_l ine ; 

450 3 text_length = size (go_ahead_question) ; 

451 3 call insert_text (@go_ahead_quest ion , text_length) ; 

452 3 call move_down line (21); 

453 3 call display_lTne ; 

454 3 call blank_line; 

455 3 call move_down line(22); 

456 3 call d i splay_lTne ; 

457 3 call rq$send$message 

(th_in_mbx, th_in_segment_token , 
return_th_in_mbx , ^status) ; 

458 3 th_in_segment_token 

= rq$receive$message 
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459 3 

460 3 


461 3 

463 3 

464 3 

465 3 

466 3 

467 3 


( return_th_i n_mbx , wa i t_fo rever , 
@duminy mbx , ^status) ; 
th_in_segment_pointer_va’lues .base 

= th_in_segment_token ; 

input_byte_index = th_in_segment . actual - 2; 

/* Check for a "g” or "G" (we aren't fussy). If */ 
/* we got it, let's quit asking the selection */ 
/* questions and go. If not, we have to start */ 
/* at question 1 again rather than try to find */ 
/* out which of his or her answers wasn't */ 

/* acceptable. */ 

if ( th_in_segment .message (input_byte index) 

= asc i i_small_gT or ~ 

( th_in_segment .message ( input_byte_index) 

= asc i i_capi tal_G ) then; 
else quest ion_number = 0; 

call blank_line; 

call move_down line (21); 

call display_lTne ; 

end ver i f y_answer s ; 

y* ************************/ 
/* As usual, the actual INPUT PARAMETERS control */ 
/■^ loop IS at tne end. */ 

y*************************y 


468 2 quest ion_number = 0; 

/* All we do is get the next question, ask the */ 
/* question until it is answered successfully, */ 
/* ask all of the questions, then check all of */ 
/* the answers. If the operator doesn't like */ 
/* the set of answers, we loop through them */ 
/* again. First we make sure the reject message */ 
/* line and other pertinent lines start out */ 


469 

2 

/* blanked, 
call blank line; 


470 

2 

call move down line 

(18) ; 

471 

2 

call display iTne; 


472 

2 

call move down line 

(21) ; 

473 

2 

call display line; 


474 

2 

call move down line 

(22) ; 

475 

2 

call display iTne; 


476 

2 

call move down line 

(23) ; 

477 

2 

call display iTne; 


478 

2 

input loop; do while question number < 3; 

479 

3 

call 

set question pointers; 

480 

3 

call 

get answer; ~ 
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481 3 

482 2 

483 2 

485 2 


end ; 

call ver i f y_answers ; 

if quest ion~n umber = 0 then goto input_loop; 
END INPUT PARAMETERS; 


y**************************** ********************/ 
/* INITIALIZE_TASKS initializes the INPUT TASK */ 
/* and the FFT TASK. If the FFT runs are to be */ 
/* continuous, INITIALIZE_TASK also initializes */ 
/* the OUTPUT TASK. If the runs are not */ 
/* continuous, the OUTPUT TASK is initialized */ 
/* by MONITOR MAILBOXES. */ 


486 

1 

INITIALIZE TASKS 

: PROCEDURE; 



487 

2 

declare 

hardware 

interrupt 

level 3 1 

iterally ' 

038H' 

488 

2 

declare 

no data 

segment 


1 i teral ly 

' OOH ' 

489 

2 

declare 

nucleus 

allocated 

stack 

literally 

' OOH ' 

490 

2 

declare 

software 

priority 

level 67 

literally 

' 67 ' 

491 

2 

declare 

software 

priority 

level 130 

literally 

'130' 

492 

2 

declare 

software 

priority 

level_131 

1 iterally 

'131' 

493 

2 

declare 

stack size 512 


literally 

'512' 

494 

2 

declare 

task 7lags~ 


literally 

'OOH' 

495 

2 

input task token 

= rq$create$task 






( software 

priority 

level 67, 

0input task. 


no data segment, nucleus al located_stack , 
stack sTze 512, task_flags, (^status) ; 

496 2 call rqScatalogSob j ec t 

(supervisor job, input_task_token , 

@ (10, ’ INPUT TASK' ) / (9¥tatus) ; 

497 2 f f t_task_token = rqScreateS task 

(¥of tware_pr ior i ty_level_131 , Of f t_task , 
no data segment, nucleus_al located_stack , 
stack_sTze_51 2 , task_flags, Ostatus) ; 

498 2 call rqScatalogSob j ect 

(supervisor_job , f f t_task_token , 

0(8, 'FFT TASK'), Ostatus) ; 

499 2 output task_token = rq$crea te$ task 

(software_priority_level_130, Ooutput_task , 
no_data_segment , nucleus_allocated_stack , 
stack size 512, task_flags, Ostatus) ; 

500 2 call rq$catalog$ob j ect 

(supervisor job, output task__token, 

0 (11, 'OUTPUT TASK'), 0 Status); 
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501 2 


502 1 

503 2 

504 2 

505 2 

506 2 

507 2 

508 2 

509 2 

510 2 


512 2 

513 2 

514 3 

515 3 

516 3 

517 2 


518 1 

519 2 

520 2 


521 2 

522 2 


523 2 

524 2 


525 2 


END INITIALIZE TASKS; 


/* Ini t ial_screen displays the initial two */ 
/* lines on the screen and sends blank lines */ 
/* for all the other lines of the first screen. */ 


INITIAL_SCREEN: PROCEDURE; 

declare initial screen index word; 


call move_down_l ine ( 0) ; 
call blank_line; 
call display_line ; 

call inove_down_l ine ( 1 ) ; 

text_length = si ze (header_l ine_one) ; 

insert_text_po inter = 0header_l ine_one ; 

call insert~text ( insert_text_poin'ter , text_length) ; 

call d isplay_l ine ; ~ ~ ~ 

call blank_line; 

do ini t ial_screen_index = 2 to 23; 

call move_down~l ine ( ini tial_screen_index) ; 
call d isplay_l ine ; 
end : ~ 


END INITIAL_SCREEN; 

y************************'*****************^ 

/* INITIALIZE_BUFFERS takes care of the */ 

/* initialization required for general */ 

/* SUPERVISOR_TASK start up. */ 

/*****************************************/ 

INITIALIZE_BUFFERS : PROCEDURE; 

return_th_in_mbx = rq$create$mai Ibox 
(queue_fifo, ^status) ; 
call rq$catalog$ob j ect 

(supervisor_job , return_th_in_mbx , 
0(9, 'SUP TH IN’)/ 0statusT; 
return_th__out_mbx = rq$create$ma i Ibox 
(queue fifo, Ostatus) ; 
call rq$catalog$obJec t 

(supervisor_job , re turn_th_out_mbx , 
0(10, 'SUP TH OUT'), 0status) ; “ 
to_input_mbx = rqScrea teSma i Ibox 

~ (queue_fifo, Ostatus) ; 

call rq$catalog$ob ject 

( supervisor_job , to_input_mbx , 

0(12, 'TO INPUT MBX'), Ostatus) ; 
to fft_mbx = rq$create$mailbox 

” ~ (queue priority, 0status) ; 
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526 2 

527 2 

528 2 

529 2 

530 2 

531 2 

532 2 

533 2 

534 2 

535 2 

536 2 

537 2 

538 2 

539 2 

540 2 

541 2 

542 2 

543 2 

544 2 

545 2 

546 2 

547 3 

548 3 

549 2 


call rq$catalog$ob j Gct 

( superv iso r_j ob , to_fft mbx , 
'a(10,'TO FFT MBX')7 (^status); 
to_output_mbx = rq$create$mai Ibox 

( queue_pr io r i ty , ©status) ; 
call rqSca talogSob j ec t 

(supervisor_job, to_output_mbx , 
@(10, 'TO OUT MBX'), ©status); 
to_supervisor_mbx = rq$create$mai Ibox 

(queue_pr ior i ty , ©status) ; 
call rq$catalog$ob j ec t 

(supervisor_job , to_supervisor_mbx , 
©(10, 'TO SUP MBX'), ©status); 


root_job_token = rq$get$task$tokens 

(rootjob, ©status); 
th_out_mbx = rq$lookup$obj ect 

(root_job_token, © (11, ' RQTHNORMOUT ’ ) , 
wai t_forever , ©status); 
th_in_mbx = rq$lookup$obj ect 

( root_job_token , © ( 10 , ' RQTHNORMIN ' ) , 
wait_forever , ©status); 

th_in_segment_token = rq$crea teSsegment 
(si ze_l 20_bytes , ©status); 
call rq$ca talog$ob j ect 

( superv iso r_j ob , th_in_segment_token , 
©(10, *S THIN SEG'), ©status) ;~ 
th_in_segment_pointer_values .of fset = 0; 
th_in_segment_pointer_values .base 

= th_in_segment_token ; 
th_in_segment . function = th_read; 

th in segment .count = 82; 


th_out_segment_token = rq$crea te$segment 
(size 120_bytes, ©status); 
call rq$catalog$obJect~ 

( supervisor_job , th_out_segment_token , 
©(11,'S THOUT SEG'T, ©status); 
th_out_segment_pointer_values .o f f set = 0; 
th_out_segment_pointer_val ues .base 

= th_out_segment_token ; 
th__out_segment . function = th_write; 

th out segment .count ~= 111; 


do general_index = 0 to 2; 

th_out_segment .home_cha rs (general_i ndex) 

= cursor_home_chars (general_index) ; 
end; ~ 


END INITIALIZE BUFFERS; 


/* At last, the SUPERVISOR TASK! All it does is */ 


37 




1101 


APPENDIX A 


/* call other procedures to initialize the */ 
/* screen, input the parameters, clean up the */ 
/* old FFT segments from the mailboxes, set up */ 
/* new segments, create the tasks, and then wait */ 
/* for messages from the operator (abort) or */ 
/* other tasks (FFT or OUTPUT done) . */ 


550 1 SUPERVISOR_TASK: PROCEDURE PUBLIC; 

551 2 call ini t ial i ze_buf f ers ; 

552 2 call rq$end$ini t$task ; 

553 2 call initial screen; 

554 2 call ini tialTze_tasks ; 

555 2 do forever; 

556 3 call input_parameters ; 

557 3 call initia’lize segments; 

558 3 call moni tor_maTlboxes ; 

559 3 end; 

560 2 END SUPERVISOR_TASK; 

561 1 END 5UPERVIS0R_M0DULE; 

MODULE INFORMATION: 

CODE AREA SIZE = 1032H 4146D 

CONSTANT AREA SIZE = OOOOH OD 

VARIABLE AREA SIZE = 0084H 132D 

MAXIMUM STACK SIZE = 0024H 36D 

1197 LINES READ 
0 PROGRAM ERROR (S) 

END OF PL/M-86 COMPILATION 
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ISIS-II PL/M-86 V2.0 COMPILATION OF MODULE INPUT_TASK_MODULE 
OBJECT MODULE PLACED IN : F 1 : i nput . OB J 
COMPILER INVOKED BY: plmS^S : FI : i nput . p8G 

Stitle (' INPUT TASK FOR AP NOTE 110, OCTOBER 1980') 
$larqe debug 
INPUT_TASK_MODULE : 
do ; 

$include ( : f 1 : nucprm . ex t) 

= $SAVE NOLIST 

89 1 declare token literally 'word'; 

/* The following two tokens, the FFT sample */ 

/* segment format, and the root job directory */ 
/* form the entire interface for this task with */ 
/* the rest of the system. */ 


90 

1 

declare 

to input mbx 

token external; 

91 

1 

declare 

to fft mbx 

token external; 

92 

1 

declare 

ascii mask 

1 i teral ly 

' 30H' ; 

93 

1 

declare 

carriage return 

literally 

' ODH' ; 

94 

1 

declare 

done 

literally 

' OFFH' ; 

95 

1 

declare 

first loop 

literally 

' OFFH' ; 

96 

1 

declare 

forever 

literally 'while 1'; 

97 

1 

declare 

frames to process entry 

literally 

'50'; 

98 

1 

declare 

hardware interrupt level 

_3 






literally ' 

' 0 038H' ; 

99 

1 

declare 

interrupt task created 

1 i terally 

' OFFH' ; 

100 

1 

1 

declare 

interrupt task not creat 

ed literally 

' 0 OH ' ; 

101 

1 

declare 

latch the~data~ 

literally 

' 0 4 OH ' ; 

102 

1 

declare 

line feed” 

literally 

' OAH' ; 

103 

1 

declare 

new fft run 

1 i teral ly 

' OFFH' ; 

104 

1 

declare 

no response requested 

1 i terally 

'OOH'; 

105 

1 

declare 

no data segment 

literally 

'OOH'; 

106 

1 

declare 

not done 

literally 

'OOH'; 

107 

1 

declare 

not first loop 

1 i terally 

'OOH'; 

108 

1 

declare 

not valid 

1 i terally 

'OOH'; 

109 

1 

declare 

null 

literally 

'OOH'; 

110 

1 

declare 

processed so far entry 

literally 

'33'; 

111 

1 

declare 

queue fif^ ” ~ 

literally 

'OOH'; 

112 

1 

declare 

root j ob 

1 i terally 

' 0 3H ' ; 

113 

1 

declare 

run continuous 

literally 'OFFFFH'; 

114 

1 

declare 

sample LSB 

literally ' 

' 0 081H' ; 

115 

1 

declare 

sample MSB 

literally 

'0080H' ; 

116 

1 

declare 

size 2 bytes 

literally 

'2'; 

117 

1 

declare 

size~’l20 bytes 

1 i terally 

'120' ; 

118 

1 

declare 

supervisor job 

li terally 

' OOH ' ; 

119 

1 

declare 

th write 

literally 

'05'; 

120 

1 

declare 

thTs is the interrupt task literally 

'OlH' ; 

121 

1 

declare 

timer one port 

literally 

' 0 0D2H ' ; 

122 

1 

declare 

timer mode control port 

xiuetdxxy 

1 nn-r\/rTT 1 . 

u u u 'o n ; 

123 

1 

declare 

valid” ” ” 

literally 

' OFFH' ; 
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124 1 declare wait forever literally 'OFFFFH'; 


125 

1 

declare 

data segment token 

token 

126 

1 

declare 

dummy mbx 

token 

127 

1 

declare 

from interrupt task mbx 

token 

128 

1 

declare 

handTer dummy mbx 

token 

129 

1 

declare 

handler status 

token 

130 

1 

declare 

interrupt status 

token 

131 

1 

declare 

interrupt task token 

token 

132 

1 

declare 

interrupt message token 

token 

133 

1 

declare 

output buffer token 

token 

134 

1 

declare 

return mbx 

token 

135 

1 

declare 

root job token 

token 

136 

1 

declare 

signal interrupt token 

token 

137 

1 

declare 

status 

token 

138 

1 

declare 

to interrupt task mbx 

token 

139 

1 

declare 

th out mbx 

token ; 

140 

1 

declare 

sample data 

integer 

141 

1 

declare 

sample input data structure( 

LSB byte , 

MSB byte) at (Psample data); 

142 

1 

declare 

current timer value 

word ; 

143 

1 

declare 

timer values structure( 



LSB byte, 

MSB byte) at (^current timer value); 


144 

1 

declare 

done flag 


byte ; 

145 

1 

declare 

first input loop 

flag 

byte ; 

146 

1 

declare 

frames received 


byte ; 

147 

1 

declare 

general index 


byte ; 

148 

1 

declare 

interrupt task flag 

byte ; 

149 

1 

declare 

sample valid 


byte ; 

150 

1 

declare 

timer threshold 


word ; 

151 

1 

declare 

value to convert 


word ; 

152 

1 

declare 

converted value 

structure ( 




first digit 


byte , 




second digit 


byte) ; 


/* The following declare is for the home */ 

/* characters for the Hazeltine terminals, */ 

/* The sequence is tilde, DC2. */ 

153 1 declare cursor_home_chars ( 2 ) byte data (07EH,012H); 

154 1 declare output buffer pointer pointer; 
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155 


156 1 


157 1 

158 1 


159 1 


160 1 

161 1 

162 2 
163 2 


declare 


outpiit_buf f er_po inter_val lies 
offset word7 

base word) at 

( floutput_buf f er pointer); 


str !jc tnre ( 


declare 


output_buf f er based output_buf f er pointer 
structure( ~ 

function word, 

count word, 

except ion_code word, 
actual word, 

home_chars ( 2) byte, 

1 ine~index ( 24 ) byte, 
character (3 0 ) byte) ; 


declare data_segment pointer pointer public; 


declare data_segment_pointer_val ues 
offset ~ word, 
base word) at 

(0data segment pointer) ; 


structure ( 


/* The following is the FFT data segment form.at, */ 
declare data_segment based data segment pointer 


structure ( 


samples per frame 

word , 

sample interval 

word , 

frames to average 

word , 

continuous flag 

word , 

this frame number 

word , 

number samples missed 

word , 

sample pointer 

word , 

reset flag 

word. 

sample (256) 

integ 


declare 


input_status line 
( ' “ The YnpuT 
' frames out 
' average. 


80) byte data 
TASK has processed 
of frames to’ 


I 

f 


FAST_INPUT_HANDLER : 

PROCEDURE (FFT_SEGMENT_POINTER) EXTERNAL; 

DECLARE FFT_SEGMENT_POINTER POINTER; 

END FAST_INPUT_HANDLER; 

y***************’*********'*’*********************** y 

/* SLOW INPUT HANDLER is an interrupt procedure */ 
/* that~recei ves an interrupt when the 3253 */ 

/* interval timer counts to zero. The 8253 is */ 
/* free running, so it starts counting from the */ 
/* top again. The 8253 counter is tested */ 

/* in a polling fashion to be sure it reads the */ 
/* sample, which resets the conversion, */ 

/* at a precise time. This aids in removing */ 
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164 1 


165 2 

166 2 


167 2 

168 2 


169 2 

1 7n 2 

171 3 

172 3 

173 3 


174 2 

175 3 

176 3 


177 3 

178 3 


179 4 

180 4 

181 4 


/* jitter from the sample intervals. When all */ 
/* of the samples have been taken, */ 
/* SLOW_INPUT HANDLER calls signal interrupt, */ 
/* which lets the INTERRLIPT_TASK procedure know */ 
/* the buffer is full. */ 


SLOW_INPUT_HANDLER: PROCEDURE INTERRUPT 59 PUBLIC; 

/* First set the sample to not_valid (we have */ 

/* to be past the timer threshold before the */ 

/* sample becomes valid) . */ 


sample_valid = not valid; 
timer_loop: ” 

/* Make the timer value stable and read it. */ 


output ( timer_mode_control_port ) = latch_the_data; 

timer_val ues . LSB = input ( timer_one_port) 7 
timer_val ues . MSB = input ( t imer_one~port) ; 

/* If it is not past the threshold, then some */ 

/* future sample will be valid. */ 

if cur rent_t imer_val ue > timer_threshold then 

do • 

sample_valid = valid; 
goto timer_loop; 
end ; 


/* We get to the else only if we are past the */ 
/* timer threshold. */ 


else 
do ; 

sample_input_data . LSB = input ( sample_LSB) ; 
sam.ple_input_data .MSB = input ( sampl e~MSB) ; 

/* If the sample is valid, we must have come */ 
/* in before the threshold so we know we */ 

/* sampled as close to the right time as */ 

/* possible. */ 

if sample_valid = valid then 
do ; 


/* However, we want to ignore the first */ 
/* sample (which was started a long */ 

/* time ago) . */ 

if f i rst_input_loop_f lag = first_loop then 
first input loop_Tlag = no t_f i rst_loop ; 
else 
do ; 
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182 5 data_segm.ent . sample 

(data_segment .sample_po inter) 

= sample_data; 

183 5 data_segment .¥ample_po inter 

= data_segment .sample_pointer+l ; 

184 5 end; 

185 4 end; 

else 

186 3 do; 

187 4 data_segment .number_samples_missed 

= data_segment .number_samples_mi ssed+1 ; 

188 4 data_segment .sample_po i nter = 0; 

189 4 end; 

190 3 sample_valid = not valid; 

191 3 end; ~ ~ 

/* If we are done, we have to let the */ 

/* INPUT_TASK know the buffer is full. */ 

/* Otherwise, we wait for the next interrupt. */ 

192 2 if data_segment ,sample_pointer 

>= data_segment . samples_per_f rame then 

193 2 call rq$signal8interrupt 

{hardware_inter rupt_level_3 , 
iahandler_status) ; 

else 

194 2 call rqSex itSinterrupt 

(hard war e_i nter r up t_level_3 , 
Ohandler_sta tus) ; 

195 2 END SLOW_INPUT_HANDLER; 

y'**************'***********************************y' 

/* INTERRUPT_TASK exists because if an interrupt */ 
/* task goes to sleep, the level of the */ 

/* interrupt task, interrupt handler, and lower */ 
/* levels remain disabled. In order to prevent */ 
/* this from happening in this application, this */ 
/* task notifies the INPUT TASK that the buffer */ 


/* is full. INPUT_TASK disables Level 3 and */ 
/* returns the token to INTERRUPT_TASK. */ 
/* INTERRUPT_TASK will then call wait interrupt, */ 
/* enabling lower levels. Since INPUT_TASK */ 
/* disabled Level 3, no Level 3 interrupts v/ill */ 
/* be serviced until Level 3 is enabled by */ 
/* INPUT_TASK. */ 
/* */ 
/* NOTE THAT PLM/86 REQUIRES THE USE OF THE */ 
/* BUILT IN INTERRUPTSPTR PROCEDURE TO OBTAIN */ 
/* THE PROPER INTERRUPT PROCEDURE ENTRY POINT. */ 
/* */ 


196 1 INTERRUPT TASK: PROCEDURE PUBLIC; 
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197 2 

198 2 

199 3 

200 3 

201 3 

202 3 

20 3 2 


204 1 


call rq$set$inter rupt 

(hardware_interr upt_level_3 , 
this_is_the_interrupt_task , 

INTERRUPT$PTR fSLOW_INPUT_HANDLER) , 

no_data_segment , interrupt_statijs) ; 

do forever; 

call rq$wa i t$ inter rupt 

(hardware_inter rupt_level_3 , 

0 inter rupt_status) ; 

call rq$send$inessage 

( f rom_inter rupt_task_mbx , 
inter r up t_message_t^ken , 

to_inter rupt_task~mbx , 0 inter rupt_status) ; 

inter rupt_message_token = rq$receive$message 
( to_inter rupt_task_mbx , wai t_forever , 
Odummy mbx , (ainterrupt status); 


end ; 

END INTERRIJPT_TASK; 

y************************************************y 
/* CONVERT DTCTTE i <? email nr- n a r- +/ 

/* convertTng a hex number into an ASCII */ 

/* number, with the advance knowledge that the */ 
/* hex number will be less than 99 decimal (in */ 
/* this case, less than 32 decimal) . */ 

y************************************************y 

CONVERT DIGITS: PROCEDURE; 


205 2 

206 2 

207 2 

208 2 
209 

3 


210 3 

211 3 


converted_val ue . f i rst_d ig i t = ascii_mask; 
conver ted_val ue . second_d ig i t = ascii_mask; 

done_flag = not_done; 

do while done_flag = not_done; 

value to convert = value to_convert - 10; 

/* The problem here is we need to check for */ 
/* a negative value when we have BYTE values */ 
/* which are, by definition, positive- and */ 
/* mudulo 256. So we adapt by checking for */ 
/* > 200 decimal, which should mean the */ 

/* value has "wrapped" around zero. If it */ 
/* has, we can get our previous value back */ 
/* by adding 10. */ 

if value_to_convert < 200 then 
converted_val ue . f i rst digit 
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212 3 

213 4 

214 4 

215 4 

216 4 

217 3 

218 2 


219 1 

220 2 

221 2 
222 2 
223 2 

2 24 2 

225 2 

226 2 

227 2 

228 2 

229 2 

230 2 


= converted_value . f i rst digit + 1; 
else “ 

do ; 

value_to_convert = value to convert + 10; 
converted value. second digit 

= converted_val ue . second_d ig i t + 
val ue_to_convert ; ~ 

done_flag = done; 
end ; 
end ; 


END CONVERT DIGITS; 


/* SEND_STATUS converts the current frame */ 
/* number into ASCII and stuffs it into the */ 
/* previously initialized status line. Then */ 
/* SEND_STATUS sends the status line to the */ 
/* terminal handler and waits for the segment */ 
/* to be returned. */ 

y'********************************'**************y 


SEND_STATUS; PROCEDURE; 

val ue_to_convert = data_segment . this_f rame_number ; 
call convert digits; 

output_buf f er .character (processed_so_far_entry) 

= converted_val ue . f i r st_d ig i t ; 
output_buf f er .character (processed_so_f ar_entry+l ) 

= converted_value.second_digit; 

value_to_convert = data_segment . f rames_to_average ; 

call convert_dig its ; 

output_buf fer .character ( f rames_to_process entry) 

= converted_va’lu¥. f irst_^igi t; 
output_buf fer .character ( f rames_to_process’ entry+1) 

= converted value. second digit; 


call rq$send$message 

( th_out_mbx , output_buf f er_token , 
return_mbx, 'astatus) ; 
output_buf f er_token = rqSreceiveSmessage 

(return_mbx, wa i t_fo rever , 
Odummy mbx , '^status) ; 


END SEND STATUS; 


/* INPUT DATxA selects the fast or slow input */ 
/* handler, initializes the 8253 timer as */ 
/* necessary, and calls the appropriate input */ 
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/* handler. Please note the values of the */ 
/* intervals selected for sampling are */ 
/* scaled by ^0/^4 so the actual frequency */ 
/* output of the 128 sample FFT algorithm will */ 
/* match up with the base 10 x axis labels. */ 
/* Base 10 doesn't map too well to a binary */ 
/* x-axis that runs from 1 to ^4. */ 


231 1 INPUT DATA; PROCEDURE; 


232 2 

233 2 

234 2 

235 2 


declare 

declare 

declare 

declare 


LSB_1 20Hz_interval literally '058H'; 
MSB_1 20Hz_interval literally '002H'; 
LSB_'=;00Hz_interval literally '028H'; 
MSB 600Hz~interval literally 'OOOH'; 


/* The 8253 timer is running at 143.6 Khz, or */ 
/* 6.5 microseconds per count. We have to */ 
/* restart the sampling process precisely, so */ 
/* we count down after the interrupt to be */ 
/* sure we are synchronized. In this case, */ 
/* we have a 300 microsecond window after the */ 
/* interrupt to get the sample. 300 */ 
/* microseconds is roughly ^2 times 6.5 */ 
/* microseconds. */ 


236 

2 

declare 

threshold for 1 2nffy. 


1 n o o pu 1 . 

2 37 

2 

declare 

threshold~for~600Hz 

1 iterally 

' 0048H ' ; 

238 

2 

declare 

a 3906 microsecond interval 






literally ' 

0F4 2H* ; 

239 

2 

dec ; are 

five places 

1 iterally 

'5'; 

240 

2 

declare 

nucleus allocated stack 

1 iterally 

' OOH ' ; 

241 

2 

declare 

shift integer right 

literally 

' SAL' ; 

242 

2 

declare 

software priority level 

0 literally 

'OOH'; 

243 

2 

declare 

software priority level 

66 literally 

'66'; 

244 

2 

declare 

stack size 512 

literally 

'512'; 

245 

2 

declare 

task flags 

literally 

'OOH' ; 

246 

2 

declare 

thi s~task 

literally 

'OOH'; 

247 

2 

declare 

timer mode control word 

1 iterally 

'74H'; 

248 

2 

declare 

enable conversion 

1 i teral ly 

'00'; 

249 

2 

declare 

input command 

1 i terally 

' 0080H' ; 


/* The first thing we do is start the conver- */ 
/* sions. We don't care about the first */ 
/* data since we are going to ignore it. Each */ 
/* time we read both bytes of the present */ 
/* converted value, we start the next */ 
/* conversion. This initialization will */ 
/* prepare for the real data gathering. */ 


250 2 output (input command) 


enable conversion; 
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251 2 

252 2 

253 3 

254 3 

255 3 

256 4 

257 4 

258 4 

259 4 

260 3 

261 4 

262 4 

263 4 

264 4 

26 5 3 

266 3 

267 3 

268 4 

269 4 

270 4 

271 4 

272 3 

273 3 


if data segment . sample interval > 391 then 
do ; 

output ( timer_mode_cont rol_po rt ) 

= timer_mode_cont roT_wo rd ; 

if data segment . sample interval 

= a_3906_microsecond_interval then 

do ; 

t imer_threshold 

= "threshold_for_l 20Hz ; 

output ( timer_one_port) 

= LSB_120Hz_interval ; 

output ( timer_one_port) 

= MSB 1 20Hz_interval ; 

end ; 
else 
do ; 

timer_threshold 

= threshold_for_600Hz ; 

output (timer_one_port) 

= LSB_600Hz_interval ; 

output ('timer_^ne_port) 

= MSB_600Hz_interval ; 
end ; ~ 

first input loop_flag = first_loop; 

if interrupt_task_f lag 

= inte’r r upt_task_not_created then 
do ; ~ 

i nter rupt_task_token = rqScrea te$task 
( so f tware_pr ior i ty_level_6 6 , 
^interrupt_task , no_data_segment , 
nucleus al loca ted_stack , 
stack sTze 512, task_flags, ^status) ; 

call rq$catalog$ob j ect 

( supervisor_job , inter r up t_task_token , 
0 (12, ' INTERRUPTTSK' ) f (^status) ; 

interrupt_task flag 

= interrupt^ task created; 


end ; 

else call rqSenable 

(hardware_inter rupt_level_3 , Ostatus) ; 

/* Now we wait until the slow handler */ 

/* fills the buffer, */ 

signal interrupt token = rq$receive8message 

~(frora int'er rupt_task_mbx , wait_forever , 
(3dummy_mbx , 0s"tatus) ; 

/* If WG get the token, we know the buffer */ 
/* is full, so we disable level 3 */ 
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274 3 

27 5 3 

27-^ 3 

277 2 

278 3 

279 3 

280 3 

281 3 


call rq$disable 

(hardware_interrupt_level_3 , Ostatus) ; 

/* And return the token so the */ 

/* INTERRUPT TASK can enable lower */ 

/* inter rupt~levels . */ 

call rq$send$message 

( to_inter rupt_task_mbx , 
signal_inter rupt_token , 
no_response_requested , Ostatus) ; 

end ; 
else 
do ; 

/* The fast INPUT handler must sample at */ 
/* precise intervals that do not allow */ 

/* variable interrupt latency. Therefore */ 

/* we raise the priority level to 0 — the */ 

/* highest — and just sample in a polling */ 

/* fashion until the buffer is filled. */ 

call rqSset$pr ior i ty 

( this_task , sof tware_pr ior i ty_level_0 , 
Ostat’us) ; 

call FAST INPUT HANDT.RR Mat;^ c^pnmpnr no^nt-pr^ . 
call rq$s¥t$pr iority 

( this_task , sof tware_pr ior i ty_level_5^ , 
Ostatus) ; 

end ; 


282 2 
283 3 


284 3 


do general_index = 0 to 127; 

data_segment .sample (general_index) 

= shi f t_integer_r ight 

(data_segment .sample (general_index) , 

f ive_places) ; 

end ; 


285 2 do general_index = 128 to 255; 

286 3 data_segment .sample (general_index ) = OOOOH; 

287 3 end; 


288 2 


289 1 

290 2 

291 2 


END INPUT DATA; 


/* UPDATE FRANE NUMBER just updates the frame */ 
/* number~parame’ter on the data segments. */ 


UPDATE_FRAME_NUMBER: PROCEDURE; 

data_segment .number_samples^missed = 0; 
data segment . sampl e_po i nter = 0; 
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292 2 

294 2 

295 2 

296 3 

297 3 

298 3 

299 2 

300 2 

301 2 


302 1 

303 2 

304 2 

305 2 

306 2 

307 2 

308 2 

309 2 

310 2 

311 2 

312 2 

313 2 


if f rairies_rece iyed = da ta_segment . f rames to average 
then f rames_received =0; ~ ~ 

if data_segment . reset_f lag = new_fft_run then 

dn r 

— jr 

f rames_received = 0; 
data_segment . reset_f lag = 0; 
end ; 

f rames_received = f rames_received + 1; 
data_segment .this f rame_number = f rames_received ; 


END UPDATE FRAME NUMBER; 


/* INITIALIZE_BUFFERS takes care of the usual */ 
/* trivia of setting up the pointers, creating */ 
/* the return mailbox, looking up the terminal */ 
/* handler, and all that other small garbage. */ 
^^■*************'******'*****'******'***************'**^ 


INITIALIZE_BUFFERS: PROCEDURE; 

return_mbx = rq$create$mai Ibox 
(queue_fifo, Ostatus) ; 

call rqScatalogSob j ect 

( supervisor_job , return_mbx, 

0(9, *I RET MBX')/ '^status); 

f rom_inter rupt_task_mbx = rq$crea te$ma i Ibox 
( que'ue_f i fo , Ostatus) ; 

call rq$catalog$obj ect 

(supervisor_job , f rom_interrupt_task_mbx , 
0(12,'FM INTSK MBX')7 0status)7 

to_inter rupt_task_mbx = rq$create$mailbox 

(queue_Tifo, ^status) ; 

call rq$catalog$ob j ect 

(supervisor_job , to_inter rupt_task_mbx , 
0(12, ‘TO TNTSK MBX“) , ^status) ; ~ 

interrupt message token = rq$crea teSsegment 
""(size 2~bytes, ^status) ; 

call rqScatalog'^^obj ect 

(supervisor_job , inter r up t_roessage_to ken , 
0 (10, ' INTTSK MSG' ) , Ostatus); 

inter rupt_task_f lag 

~= inter rupt_task_not_created ; 

output_buf f er_token = rq$create$segment 

( si’ze_l 20_bytes , 0-status) ; 

call rq$catalog$ob j ect 

(supervisor job, output_buf f er_token , 
0(10,' I BUFF SEG'), 0status) ;“ 


49 




APPENDIX B 


Intel 


314 

315 

316 

317 

318 

319 

320 


output buf f er_pointer values .of fset = 0; 

output_buf f er_po inter_values .base 
= output bUf f er_token ; 
output_buf f er . f unctTon = th_write; 
output buffer. count = 110; 
do general_index = 0 to 6; 

output_buf f er ,home_chars (general_index) 

= cursor_home_chars (general_index) ; 
end ; ~ 


321 

322 

323 


do general_index = 0 to 21; 

output_buf f er .1 ine_index (general_index) 
= line_feed; 

end ; 


324 

325 

326 


do general_index = 22 to 23; 

output_buf f er .1 ine_index (general_index) 
= n u 1 1 ; ~ ~ 

end ; 


327 

328 

329 


do general__index = 0 to 

output_buffer .character (general index) 

= input_status_l ine (general_index) ; 

end ; 


330 2 

331 2 

332 2 

333 2 


334 1 

335 2 

336 2 

337 2 


root_job_token = rq$get$task ^tokens 

th_out_mbx = rq$lookup$ob j ect 

“ (root_job_token, 0 ( 1 1 , ' RQTHNORMOUT ' ) . 
wai t_forever , Ostatus) ; 

frames received = 0; 


END INITIALIZE BUFFERS; 


y'**********************************************/ 

/* The actual INPUT_TASK begins here. It */ 
/* initializes the buffers to begin things, */ 
/* then waits forever for the FFT sample */ 
/* segment. It then samples the data, fills */ 
/* the FFT data segment, and sends it to the */ 
/* FFT_TASK. The INPUT_TASK then updates its */ 
/* status line, sends it to the terminal */ 
/* handler, and returns to the mailbox to */ 
/* wait forever. */ 


INPUT_TASK: PROCEDURE PUBLIC; 

call i ni t i al i ze_buf f ers ; 

data segment pointer val ues . o f f se t = 0; 


do forever; 
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/* Wait forever for an FFT data segment at */ 
/* the to input mbx . */ 


338 

3 

data segment token = rq$receive$message 
(tn input mhy ^ i fr»rp\7pr. 

Odummy mbx, Ostatus) ; 

339 

3 

data segment pointer values. base 
~ = data segment token; 

340 

3 

call update frame number; 

341 

3 

call input data; 

342 

3 

call send status; 

343 

3 

call rq$send$message 

(to fft mbx, data segment token 
no response requested, o¥tatus 

344 

3 

end ; 

345 

2 

END INPUT TASK; 

346 

1 

END INPUT TASK MODULE; 


MODULE INFORMATION: 

CODE AREA SIZE = 070BH 1803D 

CONSTANT AREA SIZE = OOOOH OD 

VARIABLE AREA SIZE = n036H 54D 

MAXIMUM STACK SIZE = 002AH 42D 

754 LINES READ 
0 PROGRAM ERROR (S) 

END OF PL/M-85 COMPILATION 
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MCS-86 MACRO ASSEMBLER FSTINP 

ISIS-II MCS-86 MACRO ASSEMBLER V2.1 ASSEMBLY OF MODULE FSTINP 
OBJECT MODULE PLACED IN : FI : FSTINP. OB J 
ASSEMBLER INVOKED BY: asm88 : f 1 : f st i np . a8 

LOC OBJ LINE SOURCE 


1 

2 

3 

4 

5 

8 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 


/ 

f 

; FAST_INPUT_HANDLER for APNOTE 110, 

OCTOBER 1980 
7 

; FAST_INPUT_HANDLER is an assembler routine 
that runs ¥t priority 
; level 0 and simply drives an analog to 
digital convertor and 

; stuffs the samples into a data segment until 
all of the samples 

; have been taken. FAST_INPUT_HANDLER has 
passed to it the addres's 
; of the data segment, in which the offset is 
known to be zero. 

; FAST INPUT_HANDLER returns nothing to the 
callTng routine. 

; FAST_INPUT_HANDLER provides the proper timing 

4. ^ “ 

; 39, 78, and 391 microsecond intervals using 

timed loops of 

; software instructions. In order to provide 
an FFT without large 

; amounts of jitter, the sample intervals must 
be uniform in time. 

; iRMX 86 cannot guarantee this uniformity due 
to its real_time 

; design, so this routine takes complete 
control of the processor 
; for the (39 times 128) ^.9 milliseconds or 
(78 times 128) 9.9 

; or (391 times 128) 50 milliseconds required 
to complete a frame 
; of 128 samples. 

; iAPX 86 register useage is the following: 

; AX - general BX - stack index 

; CX - loop delay counter DX - sample value 

; BP-stack SP-stack 

; DI - offset index into FFT SI - not used 

; data segment 

; DS - base for FFT data ES - not used 

; segment 
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33 

f 





34 

. ic 'k . *k k k , k k 



35 

7 





36 

f 





37 

ASSUME DS:FAST INPUT DATA, SS: STACK, 




CSrFAST INPUT CODE, ES:NOTHING 



38 

7 





39 

PUBLIC FAST INPUT 

HANDLER 




40 

7 



0080 

41 

SAMPLE LSB 

EQU 

0080H 

0081 

42 

SAMPLE MSB 

EQU 

0081H 

OOOE 

43 

FIRST PASS 

EQU 

14 

0002 

44 

SAMPLE INCREMENT 

EQU 

2 

0002 

45 

SAMPLE INTERVAL 

EQU 

2 

OlOE 

46 

SAMPLE MAX 

EQU 

270 



47 

7 





48 

9 



— 


49 

FAST INPUT DATA 

SEGMENT WORD 





PUBLIC 

'DATA' 



50 

7 



0000 

???? 

51 

LOOP VALUE 

DW 

7 



52 

7 



— 


53 

FAST INPUT DATA 

ENDS 




54 

7 





55 

7 



— 


56 

STACK 

SEGMENT 

STACK 'STACK' 



57 

7 



0000 

(20 

0000 

) 

58 


DW 

20 DUP(O) 


59 

7 



— 


60 

STACK ENDS 





61 

7 





62 

/ 



— 


63 

FAST INPUT CODE 

SEGMENT PARA 





PUBLIC 

'CODE ' 



64 

7 



0000 


65 

FAST INPUT HANDLER 

PROC 

FAR 



66 

9 



0000 

IE 

67 

PUSH DS 



0001 

55 

68 

PUSH BP 






; SAVE BP IN STACK 



0002 

8BEC 

69 

MOV BP, SP 






; SET BP TO STACK 

POINTER 


0004 

8E5E0A 70 

MOV DS, TBP + 10] 






; PUT BASE OF SAMPLE SEGMENT IN DS 

0007 

BF0200 71 

MOV DI, SAMPLE INTERVAL 





; DX IS USED TO INDEX INTO 

THE DATA SEGMENT 

OOOA 

8B05 

72 

MOV AX, DS.-rDI] 






; SET AX TO SAMPLE 

INTERVAL 

PARAMETER 

OOOC 

BFOEOO 73 

MOV DI, FIRST PASS 






; RESET DI TO FIRST SAMPLE 

- 14 

m 

v; u ur 

n T-\ ^ 

J z / 

o r\ -7 A 

U u / ^ 

HA T> -KT 

<wi’ir rt.A, oy 






; IF AX = 39, SET 

LOOP VALUE TO 9 — LOOP 

0012 

740E 

75 

JZ SET 39 US 
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; TAKES ABOUT US PER DECREMENT 
0014 3D4E00 76 CMP AX, 78 

; IF AX = 78, SET LOOP_VALUE TO 22 — BASIC 
0017 7412 77 JZ SET_78_US 

; CYCLE IS~13 US, PLUS (22 X 3) =79 US 
0019 C70600007E00 R 78 MOV LOOP_VALUE, 126 

; 391 IS ONLY ONE LEFT-13 + (126X3) 
= 391 

OOIF EB1090 79 JMP INPUT_LOOP ; 

0022 C70600000900 R 80 SET_39_US: MOV LOOP_VALUE, 9 

; TIMING IS BY SOFTWARE — SET 
DELAY COUNT 

0028 EB0790 81 JMP INPUT_LOOP 

002B C70600001600 R 82 SET_78_US: MOV LOOP_VALUE, 22 ; 

0031 8B0E0000 R 83 INPUT_LOOP: MOV CX, LOOP_VALUE 

; USE CX TO KEEP TRACK OF DELAY 
0035 E480 84 IN AL, SAMPLE_LSB 

; SET AL TO LSB OF INPUT SAMPLE 
0037 8AD0 85 MOV DL, AL 

; PUT THE LSB IN DL (8 BIT XFERS ONLY) 

0039 E481 86 IN AL, SAMPLE_MSB 

; SET AL TO MSB OF INPUT SAMPLE 
87 ; THIS RESTARTS SAMPLE PROCESS 

003B 8AF0 88 MOV DH , AL 

; PUT AL IN DH TO COMPLETE THE VALUE 
003D 83FF0E 89 CMP DI , FIRST_PASS 

; WE WANT TO SKIP THE FIRST SAMPLE 

0040 7408 90 JZ SKIP_INPUT 

0042 83C702 91 ADD DI , SAMPLE_INCREMENT 

; INCREMENT DI BY 2 
0045 8915 92 MOV DSrTDIl, DX 

; PUT SAMPLE DATA IN SEGMENT 
0047 EB0990 93 JMP DELAY 

; AND JUMP TO SOFTWARE DELAY LOOP 
004A 83C702 94 SKIP_INPUT: ADD DI , SAMPLE_INCREMENT 

; INCREMENT DI BY 2 
004D 90 95 NOP 

; AND NOP FIVE TIMES FOR EVEN TIMING 
004E90 96 NOP 

004F 90 97 NOP 

0050 90 98 NOP 

0051 90 99 NOP 

0052 90 100 DELAY: NOP 

; THIS NOP ADDS 3 CLOCKS PER DECREMENT 

0053 EOFD 101 LOOPNZ DELAY 

; DEC CX AND LOOP— 1.5 US PER DECREMENT 
0055 81FF0E01 102 CMP DI , SAMPLE_MAX 

; COMPARE DI TO SEE IF WE ARE DONE 
0059 75D6 103 JNE INPUT_LOOP 

; IF NOT, GO BACK FOR ANOTHER SAMPLE 
005B 5D 104 POP BP 

; OTHERWISE POP BP, DS , AND RETURN 
005C IF 105 POP DS 

005D CA0400 106 RET 4H 
107 
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108 

FAST INPUT HANDLER 

ENDP 

109 

110 

FAST INPUT CODE 

ENDS 

111 
1 1 2 

t 

END 


ASSEMBLY COMPLETE, NO ERRORS FOUND 
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Both the RAM and ROM-based configurations will be 
discussed in this appendix. They are essentially identical 
processes. In either case, the first step is to define a map 
of system memory. Once the map is known, the follow- 
ing sequence is suggested for locating code in memory: 

1) Reserve memory OH to 03FFH for the Nucleus in- 
terrupt vector. 

2) If the system is RAM based and the code is loaded 
by the iSBC 957A Monitor, reserve locations 
03FFH to 07FFH for the monitor’s use. 

3) Configure each of the necessary portions of the 
iRMX 86 Operating System and locate them se- 
quentially in memory. 

4) For a RAM-based development system, allow 2K of 
RAM for the system Root Job. Placing the Root 
Job after the portions of the iRMX 86 Operating 
System, which are relatively fixed in size during 
development, and before the development code will 
give the Root Job a fixed address. This will prevent 
having to move the Root Job and reconfigure the 
system when the development code grows. For final 
EPROM-based systems, the Root Job should be 
placed after the development code. 

5) Link and locate each of the application code mod- 
ules sequentially in memory. 

6) Define the RAM available to the system. 

7) Define memory NOT available to the system. This 
includes application code, EPROM, and non- 
existent memory within the 1 megabyte address 
space. 

8) Create the configuration file using the address maps 
produced by the locate steps and the memory map 
defined in steps 6 and 7. 

9) Create the Root Job from this configuration file. 

10) Load and test the system in RAM. 

1 1) If the system has been fully debugged, load the code 
into EPROM and test the final system. 

The above steps are necessary for both the RAM devel- 
opment system and the final EPROM system. Convert- 
ing this application from RAM to EPROM requires re- 
configuring the Nucleus to include only those systems 
calls required by the application, substituting the Ter- 
minal Handler Job for the Debugger Job, removing any 
remaining system calls to catalog objects for debugging, 
and remapping the system to the EPROM address 
space. The memory maps for the development and final 
application are shown in Figures C-1 and C-2. 


(RESERVED) 

RESET VECTOR 

iSBC 957A MONITOR EPROM 







SYSTEM RAM ^ 

EXPANSION 

APPLICATION DATA 

EXPANSION 

APPLICATION CODE 

ROOT JOB 

DEBUGGER 

NUCLEUS 

iSBC 957A MONITOR 

INTERRUPT VECTOR 


ADDRESS 

FFFFFH 


FFFFOH 

FDOOOH 


20000 H 
OFFFFH 
0ED50H 
0EC10H 
0EB07H 
OCOBOH 
OBACOH 
05330H 
0000 H 
OOOH 
OH 


EPROM 


NON- 

EXISTENT 


RAM 


Figure C>1. Development System Memory Map 


MODULE 


< 

(RESERVED) 

RESET VECTOR 

UNUSED EPROM 

ROOT JOB 

APPLICATION CODE 

TERMINAL HANDLER CODE ^ 

NUCLEUS CODE 






SYSTEM RAM 

ROOT JOB DATA ^ 

APPLICATION DATA 

TERMINAL HANDLER DATA 

NUCLEUS STACK 

NUCLEUS DATA 

INTERRUPT VECTOR ^ 

< 


ADDRESS 

FFFFFH 

FFFFOH 

FF5C0H 

FD3D0H 

FCAOOH 

F8000H 


04000H 

0B90H 

0B80H 

0A58H 

0990H 

0800H 

400H 

OH 


EPROM 


NON- 

EXISTENT 


RAM 


Figure C-2. Final System Memory Map 


System configuration is a straightforward but exacting 
process. As with any such processes, there are some 
hints that can make development easier. In addition to 
care in locating the Root Job in memory, users should 
fix the initialization job entry point and the data RAM 
addresses. 
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The Intel PL/M 86 programming language does not 
allow a procedure to be used until after it has been de- 
clared. This requires the initialization procedure to be 
declared after all the other procedures. Since the initial- 
ization is last, changing the other procedures will change 
the location of the initialization procedure. If the system 
entry point changes, the system must be reconfigured. 
The moving entry point can be circumvented by writing 
a separate initialization task. The Root Job will create 
only the initialization task which will then initialize the 
system jobs. The initialization task entry point is fixed 
by linking it ahead of the other application tasks and by 
not changing the initialization task during dvelopment. 
The actual system entry points will be bound to the ini- 
tialization task during linking and locating. The linking 
and locating steps are a natural consequence of chang- 


ing the application code, so binding the fixed system en- 
try point is done automatically during development. 
The fixed initialization task entry point is used in the 
configuration file, giving the Root Job an unchanging 
system entry point. 

The remaining moving target during development is the 
RAM area for data and stack use. If the data and stack 
RAM is located before or after the application code, 
with enough extra memory in between for growth dur- 
ing development, the data and stack locations can stay 
constant. Fixing both the application entry point and 
the locations of the stack and data segments will allow 
development of the application code to proceed without 
requiring frequent reconfigurations. 
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